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FROM  THE 
EXECUTIVE  EDITOR 


I  am  pleased  to  present  Issue  53  of  the  Defense 
Acquisition  Review  Journal.  We  have  an  exciting 
and  diverse  line-up  of  articles  covering  a  variety 
of  relevant  topics  for  the  acquisition  community. 

In  the  first  article,  “Command  Post  of  the  Future: 

Successful  Transition  of  a  Science  and  Technology 
Initiative  to  a  Program  of  Record”  by  BG  Flarry 
Greene,  USA,  Larry  Stotts,  Ryan  Paterson,  and  Janet 
Greenberg,  the  authors  examine  the  transition  of  Science  and  Technology 
(S&T)  into  existing  acquisition  programs.  Historically,  only  about  25 
percent  of  all  S&T  programs  successfully  transition  to  development  and 
acquisition.  One  of  the  major  issues  is  the  lack  of  sufficient  technical 
maturity.  Immature  technology  often  causes  cost  growth  and  schedule 
slips  while  the  program  manager  tries  to  address  this  problem  during  the 
development  cycle.  The  DoD  5000  series  re-write  in  2000  shows  DoD’s 
clear  intent  to  improve  technology  insertion  into  the  acquisition  process. 
As  a  part  of  this  change,  it  was  recognized  that  technical  maturity  must 
be  addressed  up  front  and  adequately  tested  before  transitioning,  but 
often  this  was  not  done.  This  article  outlines  how  the  CPOF  program  was 
successfully  transitioned  from  the  Defense  Advanced  Research  Projects 
Agency  to  the  U.S.  Army  using  a  tailored  acquisition  strategy  that  allowed 
the  new  CPOF  technology  to  be  fielded  as  a  technology  insertion  to  the 
Army  Battle  Command  System  of  Systems.  Key  to  the  success  of  this 
transition  was  the  use  of  robust  risk  management,  early  and  sustained  user 
feedback,  stable  funding,  and  honest  and  open  communication  between 
all  stakeholders.  This  acquisition  strategy  was  an  evolutionary  approach, 
tailored  to  address  the  risk  areas  over  time  rather  than  trying  to  develop 
the  perfect  product  in  the  first  delivery. 

The  second  article,  “Lead  Systems  Integrators:  A  Post-Acquisition 
Reform  Retrospective"  by  Kathlyn  Hopkins  Loudin,  addresses  concerns 
about  the  mid-1990s  Acquisition  Reform  initiatives,  which  embraced  the 
philosophy  of  “partnering  with  industry.”  This  philosophy  led  to  business 
relationships  with  various  titles  throughout  DoD.  The  "Lead  Systems 
Integrator”  (LSI)  concept  was  most  used  by  the  Army.  Correspondingly, 
the  “Design  Agent”  concept  was  used  in  the  Navy,  and  the  “Total  System 
Performance  Responsibility”  (TSPR)  was  very  popular  in  Air  Force 
contracts.  These  concepts  were  the  result  of  a  series  of  laws,  policies, 
reforms,  and  initiatives  embracing  the  Acquisition  Reform  movement  of 
the  1990s.  A  key  assumption  of  all  these  concepts  was  that  cost-efficiency 
could  be  improved  by  using  contractors  more  effectively  and  giving  them 
more  powerful  roles.  The  general  result  of  all  these  business  models  was 
to  shift  more  systems  development  and  systems  engineering  work  to  the 


private  sector.  While  this  approach  has  some  advantages,  it  also  resulted 
in  a  de-emphasis  of  organic  systems  engineering  capability  within  DoD. 
Recent  critics  have  asserted  that  these  concepts  have  driven  cost  growth 
and  have  undermined  DoD’s  ability  to  control  major  acquisition  programs. 
However,  the  data  suggest  that  the  use  of  LSI  strategies  is  not,  by  itself,  a 
good  predictor  of  cost  growth.  The  author  analyzes  these  concepts  and 
makes  recommendations  about  future  optimization  of  these  types  of  roles. 

The  third  article,  "Achieving  Outcomes-Based  Life  Cycle  Manage¬ 
ment”  by  Lou  Kratz  and  Bradd  A.  Buckingham,  explores  fundamental 
changes  needed  within  government  and  industry  to  evolve  a  highly  ag¬ 
ile  and  responsive  life  cycle  process.  For  decades,  the  Department  of 
Defense  has  attempted  to  improve  its  acquisition  and  life  cycle  process 
through  a  series  of  incremental  changes  to  address  major  challenges, 
such  as  requirements  creep,  evolving  threats,  cost  growth,  funding  in¬ 
stability,  and  technical  risk.  Unfortunately,  these  changes  have  not  met 
expectations.  Currently,  the  United  States  faces  significant  economic 
and  national  security  threats  from  rogue  states  and  transnational  terror¬ 
ist  organizations.  DoD  acquisition  and  life  cycle  sustainment  processes 
are  straining  under  the  demands  of  the  Global  War  on  Terror  and  an 
emerging  shortage  of  skilled  acquisition  and  sustainment  professionals. 
Cost/schedule  growth,  extended  development  cycles,  schedule  delays, 
elongated  logistics  response  times,  and  increasing  backorders  are  evi¬ 
dence  of  those  strains.  These  threats  and  challenges  require  an  agile, 
cost-efficient  process  to  mature  and  sustain  military  capabilities.  This 
article  addresses  fundamental  changes  needed  within  government  and 
industry  to  evolve  a  highly  agile  and  responsive  life  cycle  process. 

The  fourth  article,  “Pre-Milestone  A  Cost  Analysis:  Progress, 
Challenges,  and  Change”  by  Martha  "Marti”  A.  Roper,  deals  with  one  of 
the  most  challenging  and  most  important  issues  early  in  the  acquisition 
cycle— effective  cost  estimating  and  cost  analysis.  As  a  result  of  the  2004 
Quadrennial  Defense  Review's  emphasis  on  earlier  investment  decision 
making,  the  Office  of  the  Under  Secretary  of  Defense  (Acquisition, 
Technology,  &  Logistics),  sponsored  a  study  to  examine  the  opportunities 
to  improve  early  cost  estimating  in  acquisition  programs.  A  team  of  Army 
analysts  at  the  Office  of  the  Deputy  Assistant  Secretary  of  the  Army  for 
Cost  and  Economics  conducted  the  3-year  research  study  resulting  in 
some  important  lessons  learned.  Clearly,  the  biggest  challenge  was  how 
to  develop  cost  estimates  so  early  in  the  life  cycle,  with  so  little  system 
definition.  The  analysts  found  three  major  elements  that  enable  pre- 
Milestone  A  cost  estimating.  The  first  is  an  analysis  framework  that  can 
make  use  of  qualitative  capability  data  to  produce  a  cost  estimate.  The 
second  is  a  cumulative  high-level  cost  data  source  that  links  systems  to  their 


capability  sets.  The  third  is  an  analysis  culture  with  the  policy,  procedure, 
and  willingness  to  develop  and  accept  cost  estimates  that  are  less  precise 
than  those  developed  at  Milestone  B  or  Milestone  C.  This  research  makes 
the  case  that  Pre-Milestone  A  cost  analysis  can  be  the  foundation  upon 
which  sound  investment  decision  making  is  built. 

The  fifth  article,  “The  Demise  of  the  Federal  Government  Small 
Business  Program”  by  Philip  G.  Bail  Jr.,  traces  the  history  of  federal 
government  interaction  with  small  businesses  in  the  United  States  and 
offers  a  warning  that  the  current  state  of  small-business  setaside  is 
unsustainable.  The  author  presents  a  comprehensive  summary  of  federal 
policy  and  legislation  beginning  with  the  Herbert  Hoover  administration 
in  1929.  The  DoD  became  directly  involved  in  this  issue  by  the  creation  of 
the  Armed  Services  Procurement  Act  of  1947.  The  author  discusses  how 
numerous  laws  and  public  policy  decisions  regarding  small  business  policy 
have  been  implemented  by  the  federal  government  and  DoD.  Despite 
many  efforts,  the  government’s  attempts  to  increase  small  business’s  share 
of  federal  contracts  have  not  been  totally  successful.  The  author  offers 
recommendations  and  suggestions  on  how  the  federal  small  business 
program  can  become  a  viable  one  that  benefits  small  businesses  so  they 
truly  get  an  equitable  share  of  government  dollars. 

The  sixth  article,  “Building  on  a  Legacy:  Renewed  Focus  on  Systems 
Engineering  in  Defense  Acquisition”  by  Mary  C.  Redshaw,  provides  a 
historical  context  of  the  systems  engineering  discipline  in  DoD,  outlines 
the  evolution  of  process  models  and  terminologies,  and  analyzes  the 
implications  of  terminology  changes  recently  introduced  in  the  Defense 
Acquisition  Guidebook  (DAG)  released  in  2009.  Because  of  DoD’s  role  in 
developing  and  acquiring  large  and  complex  systems,  defense  acquisition 
managers  initially  led  the  effort  to  formalize  the  systems  engineering 
process  by  publishing  Military  Standard  499  (MIL-STD-499)  in  1969.  This 
baseline  documented  the  first  formal  consensus  standard  governing 
the  systems  engineering  community  of  practice.  There  have  been  many 
iterations  and  changes  in  how  systems  engineering  is  viewed  and  applied 
throughout  the  DoD  and  the  defense  industry  since  1969.  Redshaw 
expertly  navigates  the  reader  through  the  evolution  of  these  changes  in 
process  and  philosophy. 

The  seventh  article,  “Open  Systems:  Designing  and  Developing  our 
Operational  Interoperability"  by  MAJ  James  Ash,  USA  (Ret.)  and  LTC 
Willie  J.  McFadden  II,  USA  (Ret.),  makes  a  case  for  the  growing  importance 
of  using  an  Open  Systems  approach  in  defense  systems  due  to  today’s 
complex  threat  environment  and  interoperability  needs.  The  authors 
examine  the  attributes  of  an  open  systems  approach  to  technology 
insertion  and  operational  readiness.  Due  to  the  changing  nature  of  warfare 
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and  increased  operational  demands,  the  need  for  technological  innovation 
is  continually  increasing;  however,  insertion  of  technology  brings  additional 
problems  and  constraints  (fiscal,  technological,  and  logistical  challenges) 
that  must  be  addressed.  The  authors  argue  that  a  possible  solution  to 
incorporating  new  technologies  into  current  systems  is  to  intensify  efforts 
to  achieve  a  true  open  systems  environment. 

The  eighth  article,  “A  Time  Study  of  Scientists  &  Engineers  (S&Es) 
in  the  Air  Vehicles  Directorate”  by  JoAnn  McCabe  and  Col  John  Wissler, 
USAF,  addresses  the  issue  of  how  much  time  government  scientists  and 
engineers  actually  spend  doing  technical  work,  as  opposed  to  other 
bureaucratic,  non-technical  work.  This  article  resulted  from  a  case  study 
done  at  the  Air  Vehicles  Directorate  of  the  Air  Force  Research  Laboratory 
(AFRL)  at  Wright-Patterson  Air  Force  Base,  where  about  600  people 
are  employed.  Approximately  one-third  of  these  are  S&Es  who  develop 
advanced  flight  vehicle  technologies  in  the  areas  of  aerodynamics,  flight 
control,  and  structural  sciences.  These  technologies  can  be  found  in 
virtually  every  major  weapon  system  in  the  Air  Force.  In  response  to  budget 
cuts  and  efficiency  reforms,  the  workforce  in  the  Air  Vehicles  Directorate 
has  declined  16  percent  in  the  last  decade.  Many  of  these  cuts  resulted 
in  the  reduction  of  non-technical  personnel,  often  leaving  additional  non¬ 
technical  work  tasks  to  the  S&Es.  Concerns  have  been  raised  to  leadership 
that  the  technical  workforce  is  not  accomplishing  enough  technical  work. 
Therefore,  the  questions  for  AFRL  are:  1)  Flow  much  real  technical  work  are 
the  S&Es  doing?  and  2)  Is  this  the  right  mix?  This  article  summarizes  the 
initial  time  study  completed  at  the  Air  Vehicles  Directorate  and  provides 
several  leadership  initiatives  intended  to  address  this  situation. 

The  final  article  from  the  Defense  Acquisition  University  (DAU) 
Technology  Corner  is  written  by  DAU’s  resident  historian,  social 
anthropologist,  and  technologist  Mark  Oehlert.  Oehlert  works  in  the 
Global  Learning  Technologies  Center  at  the  DAU.  His  duties  focus  on  the 
use  of  social  media  in  acquisition  workforce  education  and  development. 
He  offers  a  thought-provoking  piece  providing  insight  on  how  to  address 
the  challenges  of  introducing  new  technologies  and  communication 
opportunities  within  an  organizational  culture. 

I  hope  you  will  enjoy  this  issue  as  much  as  we  enjoyed  putting  it 
together. 


Dr.  Paul  Alfieri 
Executive  Editor 
Defense  ARJ 
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COMMAND  POST  OF  THE 
FUTURE:  SUCCESSFUL 
TRANSITION  OF 
A  SCIENCE  AND 
TECHNOLOGY  INITIATIVE 
TO  A  PROGRAM  OF 
RECORD 

(  BG  Harry  Greene,  USA,  Larry  Stotts, 

Ryan  Paterson,  and  Janet  Greenberg 

This  article  outlines  how  the  Command  Post  of  the  Future 
(CPOF)  program  was  successfully  transitioned  from  the 
Defense  Advanced  Research  Projects  Agency  (DARPA) 
to  the  U.S.  Army.  Use  of  a  tailored  DoD  5000  acquisition 
strategy  allowed  the  new  CPOF  technology  to  be  fielded 
as  a  technology  insertion  into  the  Army  Battle  Command 
System  (ABCS).  Key  to  the  success  of  this  transition  included 
the  use  of  risk  management  techniques  to  drive  the  program 
forward,  use  of  early  and  sustained  feedback  from  the  user 
community,  maintaining  transition  funding  stability,  and 
honest  and  open  communication  between  all  stakeholders. 

The  DoD  5000  acquisition  strategy  was  tailored  to  fix  the 
risks  over  time,  rather  than  trying  to  develop  the  perfect 
product  in  one  delivery. 


Keywords:  Command  Post  of  the  Future  (CPOF), 
Battle  Command,  Science  and  Technology  (S&T) 
Initiative,  Risk  Management,  Tailored  Process,  Army 
Battle  Command  System  (ABCS) 
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Background 


In  1999,  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and 
Logistics  Jacques  Gansler  tasked  [then]  Director,  Defense  Research  and 
Engineering  (DDR&E)  Hans  Mark  to  find  out  how  many  Service  Science 
and  Technology  (S&T)  programs  make  it  from  research  into  development 
and  acquisition.  This  tasking  was  part  of  the  under  secretary’s  effort  to 
develop  a  plan  for  Acquisition  Reform.  After  conducting  a  comprehensive 
workshop,  the  participants  determined  that  for  all  the  Services  only  about 
25  percent  of  all  S&T  programs  transitioned.  One  of  the  major  issues  was 
technical  maturity  of  the  S&T  results,  which  often  caused  cost  growths 
and  schedule  slips  while  the  program  manager  tried  to  fix  problems  during 
the  development  cycle.  The  result  was  a  complete  rewrite  of  the  5000 
series  (Department  of  Defense,  2000),  as  illustrated  in  Figure  1,  which 
clearly  shows  that  S&T  products  can  be  inserted  throughout  the  entire 
process.  The  intent  was  to  get  more  products  transitioning  from  the  S&T 
community  to  acquisition  programs. 


FIGURE  1.  DEVELOPMENT  AND  ACQUISITION  PROCESS  (AS 
OUTLINED  IN  DOD  5000.2) 


Technology  Opportunities  &  User  Needs 


►  Process  entry  at  Milestones  A,  B,  or  C  (or  within  phases) 

►  “Entrance  criteria”  met  before  entering  phase 
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Sustainment 


As  part  of  this  new  process,  the  rewrite  team  recognized  that  technical 
maturity  must  be  addressed  up  front.  Usually,  technology  was  not 
tested  thoroughly;  rather,  it  was  often  transferred  to  acquisition  without 
knowledge  of  how  well  the  technology  worked  or  what  improvements  were 
needed  to  build  a  reliable  product.  In  response,  the  minimum  entrance 
requirement  for  any  S&T  products  at  Milestone  (MS)  B  was  a  Technology 
Readiness  Level  (TRL)  6.  The  TRL  6  entrance  criterion  for  Milestone  B 
was  chosen  because  it  provided  the  government  with  confidence  that  the 
proposed  technology  would  not  require  multiple  test  cycles.  This  requires 
some  developmental-like  testing  prior  to  MS  B,  as  well  as  some  Limited 
User  Tests  (LUTs)  to  minimize  risk. 

This  article  outlines  how  the  CPOF  program  was  initiated,  executed, 
and  transitioned.  By  documenting  our  experiences,  we  hope  to  provide 
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the  research,  development,  and  acquisition  communities  an  example  of 
best  practices  that  actually  worked.  Specifically,  we  seek  to  show  readers 
how  to  successfully  transition  S&T  products  to  create  new  capabilities  for 
the  Army  of  the  future. 


WHAT  IS  CPOF? 

Command  Post  of  the  Future  is  a  planning  and  mapping  tool  intended 
for  collaboration  between  multiple  echelons  in  a  tactical  environment 
(Myers  et  al,  2002,  pp.  343-348).  In  1997,  the  Defense  Advanced  Research 
Projects  Agency  (DARPA)  began  developing  the  CPOF,  using  a  team 
of  retired  senior  officers  and  experts  in  cognitive  psychology,  human- 
computer  interfaces,  and  computer  technology.  The  team  developed 
the  CPOF  as  a  commander-centric  software  environment.  CPOF  is  an 
intuitive  and  easy-to-learn  system  that  supports  2D  and  3D  visualization 
that  can  be  uniquely  tailored  to  suit  the  user’s  individual  requirements.  It 
was  specifically  developed  to  enable  distributed,  collaborative,  command 
and  control,  rather  than  simply  allowing  applications  to  share  information. 
CPOF  supports  deep  collaboration— collaboration  at  the  thought  process 
level  that  literally  allows  commanders,  subordinates,  and  key  battle  staff 
to  see  what  the  commander  is  thinking. 

CPOF  integrates  government-developed  software  with  Commercial- 
Off-The-Shelf  (COTS)  software  to  provide  a  workspace  tool  containing 
various  frames  such  as  charts,  tables,  and  customized  appliances 
specific  to  the  application.  Further,  it  supports  parallel,  synchronous  and 
asynchronous,  cross-functional  planning  and  execution;  and  provides  for 
bi-directional  interoperability  with  Army  Battle  Command  System  (ABCS) 
and  other  Department  of  Defense  (DoD)  systems. 

The  sharing  and  collaboration  of  intelligence  and  other  information 
via  voice  and  visualization  techniques,  within  a  distributed  architecture,  is 
also  supported  by  CPOF.  It  also  provides  the  capability  to  simultaneously 
collaborate  and  share  data  and  information  horizontally  among  operators 
at  the  same  echelon  and  vertically  between  operators  at  other  echelons  in 
real-time.  The  ability  to  collaborate  among  analysts  at  an  echelon,  between 
echelons,  and  with  battalions  is  key  to  achieving  information  dominance. 
And  information  dominance  is  critical  to  the  ability  of  the  CPOF  systems 
to  provide  the  warfighting  commander  with  an  enhanced  local  and  multi¬ 
echelon  situational  awareness,  which  promotes  synchronized  operational 
planning  and  execution. 


PROGRAM  HISTORY  IN  DARPA 

Figure  2  shows  an  overview  of  the  history  of  the  CPOF  program.  It 
started  in  the  early  1990s  as  a  research  effort  on  expert  systems  design. 
Development  continued  under  the  auspices  of  DARPA,  concentrating  on  the 
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FIGURE  2.  HISTORY  OF  CPOF  PROGRAM 


1994-1996: 

Development  of  information-centric  Ul 
paradigm.  Founded  on  cognitive  psychology 
and  human-computer  interaction  principles, 

Visage  system  supports  natural  interactions  in 
highly  information-intensive  environments. 

1998-2003: 


Oct  2003: 

Decision  to  field 
CPOF  to  1CD. 


Application  of  CoMotion  to  Command  and 
Control  problem  creation  of  lab  prototype 
for  CPOF.  Evolution  of  the  Double  Helix 
design  methodology. 


Apr  2005: 

General  Dynamics 
C4Systems  acquires 
MAYA  Viz. 
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Basic  Research  (CMU  and  MAYA  Design) 

Systems  (MAYA  Viz): 

j  Transition  (MAYA  Viz  and  General  Dynamics): 
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Early  1990s: 

Development  of  SAGE  expert 
system  automating  visualization 
design,  based  on  characteristics 
of  data  and  user  tasks. 

1996-1997: 

Visage-Link  extends 
information-centric  Ul  to 
deep  collaboration  model. 


1998 


1998: 

MAYA  Viz  founded  to 
build  CoMotion  product 
capturing  principles  of 
information-centrism 
and  deep  collaboration. 
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2003-2005: 

Intense  focus  on  taking  lab  prototype  for 
CPOF  and  making  it  scalable  and  deployable 
to  transition  to  the  Army  PEO. 
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design  of  a  user  interface  that  would  be  intuitive  in  an  information-intensive 
environment  like  that  found  in  tactical  Army  Command  and  Control. 

The  history  of  CPOF  at  DARPA  is  broken  out  into  four  very  distinct 
phases,  which  were  led  by  three  different  program  managers;  the  program 
endured  at  DARPA  from  1997  until  it  fully  transitioned  to  the  Army  in  2006. 

During  the  initial  phase  of  the  program,  DARPA  invested  in  exploring  rich 
display  technologies,  artificial  intelligence  agents,  learning  technologies, 
and  inference  engines.  This  phase  looked  toward  the  future  command 
post— a  high  tech  theater  where  commanders  would  be  assisted  by 
intelligent  agents  in  making  battlefield  decisions,  and  where  holographic 
and  high  resolution  displays  would  turn  the  Tactical  Operations  Center 
(TOC)  of  today  into  a  command  theater. 

With  Phase  I  complete,  DARPA  received  some  very  specific  guidance 
from  senior  officers  in  the  Army  and  Marine  Corps  about  the  efforts  to 
create  a  high  tech  command  theater.  During  this  phase,  retired  military 
advisors  led  technologists  through  a  series  of  decision  support  exercises, 
including  field  exercises.  The  intent  of  this  phase  was  to  bring  military 
operators  and  technologists  into  the  same  environment,  creating  an 
atmosphere  where  the  technology  and  operations  could  co-evolve. 

The  CPOF  interface  was  developed  and  refined  during  the  third  phase 
of  the  program.  Working  in  conjunction  with  the  Marine  Corps  Warfighting 
Lab  and  active  duty  units  from  the  Army  and  Marine  Corps,  a  unique 
development  environment  was  created.  It  tightly  coupled  operators  and 
technologists  as  they  explored  the  possibility  of  radical  changes  in  the 
way  operators  perform  their  jobs  with  new  technologies. 
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In  the  fall  of  2003,  CPOF  was  introduced  to  [then]  MG  Peter  W. 
Chiarelli,  USA,  commander  of  the  1st  Cavalry  Division  (1CD).  MG  Chiarelli 
requested  that  CPOF  deploy  with  his  division  to  Iraq.  In  this  phase— 42 
systems  and  servers— a  team  of  technical  and  operations  subject  matter 
experts  were  deployed  in-theater.  In  March  of  2004,  working  with  MG 
Chiarelli,  the  DARPA  team  deployed  systems  throughout  the  division 
headquarters  and  to  each  of  the  brigade  headquarters.  The  deployment 
team  was  able  to  work  with  operators  to  incorporate  CPOF  into  part  of 
their  daily  battle  rhythm. 

With  the  early  success  of  CPOF  and  its  deployment  with  1CD, 
an  agreement  was  codified  in  a  Memorandum  of  Agreement  (MOA) 
between  DARPA  and  the  Department  of  the  Army.  This  agreement  called 
for  continuing  the  deployment  of  CPOF  to  Iraq  as  an  experiment,  and 
furthering  the  experiment  by  fielding  CPOF  to  two  additional  divisions  in 
subsequent  years.  It  also  provided  for  a  subsequent  decision  on  transition 
of  CPOF  to  an  Army  Program  of  Record  (POR).  Transition  was  dependent 
on  three  measures: 

•  The  ability  to  scale  CPOF  to  200  users 

•  Demonstration  of  the  use  of  CPOF  over  standard  tactical 
communications 

•  Demonstration  of  interoperability  with  the  ABCS. 


OPERATIONAL,  TECHNICAL,  AND  PROGRAMMATIC  COLLABORATION 

With  the  1CD  deployment  into  Iraq  underway,  a  collaborative  effort 
between  DARPA  and  the  Army  began  in  earnest.  DARPA’s  efforts  to  date 
had  been  focused  on  creating  the  most  intuitive  collaborative  interface. 
Very  little  work  had  been  conducted  to  harden  the  system  for  operations 
in  a  tactical  environment.  Together,  a  team  that  included  a  Marine  Corps 
program  manager  from  DARPA,  soldiers  from  the  Army’s  Training  and 
Doctrine  Command  (TRADOC)  and  1CD,  and  acquisition  professionals 
from  PEO  C3T  (Program  Executive  Officer,  Command,  Control,  and 
Communications-Tactical)  and  Army  G-8,  worked  to  put  in  place  a  2-year 
plan  to  cover  operational,  technical,  and  programmatic  concerns.  Senior 
leadership  of  the  division  took  ownership  of  the  test-fix-test  process, 
allowing  warfighters  to  dictate  the  requirements.  MG  Chiarelli  understood 
the  technical  issues  that  needed  to  be  conquered,  and  was  willing  to 
accept  the  risk  to  see  CPOF  successfully  integrated  into  the  division. 

In  parallel  with  MG  Chiarelli’s  use  of  CPOF  in-theater,  the  Army  and 
DARPA  decided  to  look  at  how  best  to  continue  CPOF  development. 
DARPA  and  the  Army  came  to  an  agreement,  documented  in  the  2004 
MOA.  DARPA  would  continue  to  fund  the  advanced  technology  research 
needed  to  harden  the  system  and  exploit  technical  lessons  learned.  The 
Army  would  fund  the  operational  support  and  hardware  procurements 
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necessary  to  execute  the  continued  fieldings.  During  this  collaborative 
phase  of  the  program,  DARPA  provided  $13.5  million  of  funding,  and  the 
Army  provided  $37.5  million.  DARPA  would  maintain  primary  control  of 
the  program  for  2  years.  The  MOA  also  called  for  CPOF  fieldings  to  three 
Army  Divisions  (Operation  Iraqi  Freedom  2  through  4)  and  technological 
improvements  to  CPOF  software  in  the  areas  of  scaling,  satellite 
communications,  and  ABCS  integration. 

Some  hurdles,  however,  needed  to  be  overcome— none  of  which  were 
insignificant  in  the  way  the  acquisition  community  procures  new  systems. 

•  DARPA’s  involvement  with  and  funding  of  CPOF  was 
scheduled  to  end  at  the  conclusion  of  the  1CD  rotation  in  Iraq. 

•  CPOF  was  not  in  the  Army  Program  Objective  Memorandum 
for  funding,  nor  was  there  an  office  established  that  would 
be  able  to  take  on  a  new  program  with  many  technical 
challenges  still  ahead. 

•  No  approved  requirement  document  was  in  place  calling  for 
a  stand-alone  system  like  CPOF. 

•  CPOF  needed  to  meet  the  requirements  imposed  by  the 
acquisition  regulations  and  laws. 

•  Significant  risks— namely  scalability,  performance,  and 
ABCS  interoperability— still  needed  to  be  reduced  to  enable 
a  broader  use  of  CPOF. 

•  CPOF  had  minimal  capability  to  interoperate  with  other 
Army  and  Joint  systems. 

To  tackle  these  hurdles  and  maintain  the  momentum  of  the  CPOF 
program,  the  PEO  C3T  and  DARPA  joined  forces. 

The  Army  Acquisition  Executive  (AAE)  assigned  CPOF  management 
authority  to  PEO  C3T,  and  directed  that  the  designated  program 
management  office  enter  into  an  agreement  with  DARPA  to  support  the 
transition  of  CPOF  technology  to  the  Army.  PEO  C3T  gave  responsibility 
for  CPOF  to  PM  Battle  Command.  In  October  2004,  the  Army  opened  a 
small  program  office  for  CPOF. 

The  2  years’  leadership  overlap,  from  2004  to  2006,  between  DARPA 
and  the  Army  allowed  time  for  relationships  to  develop,  for  technology 
transfer  to  occur,  and  for  the  acquisition  steps  necessary  for  an  Army 
POR  to  be  developed  and  approved.  The  Army  PM  shop  integrated  CPOF 
requirements  into  the  Maneuver  Control  System  (MCS)  Capabilities 
Production  Document  (CPD),  wrote  a  Test  and  Evaluation  Master  Plan 
(TEMP),  and  obtained  the  necessary  Army  and  Joint  approvals  necessary 
to  field  and  sustain  a  POR. 

Formal  transition  of  CPOF  to  the  Army  occurred  in  April  2006,  and 
is  documented  in  PEO  C3T’s  CPOF  Decision  Point  1  (DPI)  Acquisition 
Decision  Memorandum  (ADM). 
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Ongoing  Development 


MODELING  AND  SIMULATION 

CPOF  developers  relied  on  modeling  and  simulation  as  well  as  heavy 
experimentation  to  quickly  grow  CPOF  into  a  successful  theater-wide 
system.  CPOF  had  three  major  technical  challenges  to  overcome  in  the 
near  term:  scalability,  system  stability,  and  ABCS  interoperability.  To  meet 
these  challenges,  new  technologies  and  data  management  strategies 
were  modeled  for  their  impact  on  the  architecture.  For  example,  a  mid¬ 
tier  server  concept  was  introduced  to  ease  the  bandwidth  utilization  over 
tactical  networks.  Through  modeling  and  experimentation,  CPOF  was 
able  to  demonstrate  significant  bandwidth  reduction. 

The  first  step  in  any  effort  to  develop  software  is  to  get  consensus 
from  the  user  community,  including  the  direct  users,  on  a  concise  set 
of  requirements.  Often  this  can  be  difficult,  but  since  CPOF  was  fielded 
to  select  users  as  a  commander’s  tool  in  2004,  direct  user  feedback 
was  readily  available.  The  user  and  Field  Support  Representative 
(FSR)  feedback  was  the  primary  source  used  to  define  and  refine  the 
requirements.  Each  time  a  new  capability  was  added,  it  was  evaluated  and 
feedback  was  again  given  by  the  end-users  and  the  FSRs.  This  constant 
feedback  loop  provided  gradually  increased  capability  by  allowing  the 
software  developers  to  focus  directly  on  the  issues  identified  by  the 
users.  It  produced  a  higher  quality,  more  useful  end  product  in  a  very 
short  period  of  time. 

The  use  of  experimentation  reduces  program  risk  by  continually 
testing  out  new  functionality  and  incorporating  real-world  feedback. 
Resources  are  not  applied  against  a  capability— either  hardware  or 
software— until  the  users  and  support  people  concur  that  it  is  worth  the 
cost  and  additional  risk. 


SPIRAL  DEVELOPMENT 

The  employment  of  end-user  and  FSR  feedback  in  an  “experimentation” 
mode  allowed  a  tighter  or  faster  spiral  development  process  to  occur 
(vice  the  traditional  software  waterfall  development).  Following  is  a 
description  of  the  key  capabilities  of  the  first  two  major  spirals  in  the  CPOF 
development,  each  about  a  year  apart. 

CPOF  version  2.4  was  the  version  resulting  from  the  spiral  development 
that  was  occurring  in-theater.  Some  characteristics  of  this  version  are: 

•  Operates  with  latency  of  up  to  1400  ms 

•  Bandwidth  use  up  to  18-28  Mbps  during  peak  usage  to 
support  a  division  fielding 
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•  Scaled  to  200-250  users  on  a  single  master  repository,  with 
40  users  at  the  mid-tier 

•  Supports  7  ABCS  threads  and  41  common  tactical  graphics. 

The  next  version,  CPOF  3.0  that  4th  Infantry  Division  used,  improved 
all  of  these  characteristics: 

•  Operates  with  latency  of  up  to  2,100  ms 

•  Bandwidth  use  up  to  5-6.5  Mbps  during  peak  usage  to 
support  a  division  fielding 

•  Scaled  to  300+  users  on  a  single  master  repository,  with  60 
users  at  the  mid-tier 

•  Supports  14  ABCS  threads  and  89+36  common  tactical 
graphics 

•  Increases  stability  via  almost  300  CPOF  bug  fixes. 

Figure  3  shows  the  CPOF  maturation  and  development  through  present 
day  that  continues  to  address  warfighter  issues. 


FIGURE  3.  CPOF  MATURATION  OVER  TIME 
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At  this  point  CPOF  had  met  the  Army  criteria  for  transition  from 
DARPA  to  the  Army  in  the  April  2004  MOA.  In  parallel  with  the  DARPA- 
sponsored  spiral  development  work  in-theater,  the  Army  program  office 
developed  an  acquisition  strategy  to  transition  the  program  into  a  POR. 


DEVELOPMENT  OF  THE  BATTLE  COMMAND  VISION  FOR  THE  FUTURE 

The  Battle  Command  Migration  Plan  was  developed  and  refined  to 
map  out  the  development,  fielding,  and  finally,  retirement  path  for  ABCS 
for  the  near-  and  long-term  future.  It  was  developed  in  the  context  of  the 
current  Army  environment— the  Army  at  war  in  Operation  Iraqi  Freedom/ 
Operation  Enduring  Freedom  (OIF/OEF),  the  need  for  increased  Joint 
interoperability,  and  Future  Combat  Systems/Net-Enabled  Command 
Capability  (FCS/NECC)  schedules.  The  plan  took  into  account  the  need  for 
technology  insertions  due  to  the  rapidly  changing  available  commercial 
products,  and  the  need  to  upgrade  existing  software  to  better  use  the 
technologies  that  are  available.  The  goals  of  the  Battle  Command  Migration 
Plan  included  lowering  life  cycle  cost  by  moving  to  a  smaller  footprint; 
making  the  systems  easier  to  use,  train,  and  configure;  and  fielding  a  single 
standard  capacity  to  every  unit  that  provides  the  basis  for  their  unique 
tailoring  needs. 

CPOF  was  one  of  the  first  technology  insertions  into  the  existing 
ABCS  6.4  System  of  Systems.  The  Battle  Command  vision  is  to  leverage 
the  CPOF  technology,  including  its  collaboration  services  and  graphical 
user  interface,  as  a  front  end  for  all  Battle  Command  applications/users 
and  possible  transformation  into  the  single  visualization  system  for  Battle 
Command.  Key  development  tasks  are  planned  to  enable  this,  including; 

•  Defining  an  open  set  of  Application  Program  Interfaces 
(APIs)  and  a  Third  Party  Development  Kit  (3PDK)  to  enable 
multiple  vendors  to  build  CPOF-enabled  modules  for 
specialized  Battle  Command  functionality 

•  Leveraging  DoD  standard  mapping  services,  such  as  the 
Commercial/Joint  Mapping  Tool  Kit  (C/JMTK),  to  provide 
a  richer  set  of  mapping  capabilities,  including  common 
symbology  and  maps 

•  Leveraging  common  Active  Directory  services  for  common 
user  management  and  authentication  across  CPOF  and  the 
Battle  Command  infrastructure 

•  Leveraging  a  future  PEO-provided  Tactical  Enterprise 
Voice  Over  Internet  Protocol  (VOIP)  solution;  Warfighter 
Information  Network-Tactical  (WIN-T)  is  the  targeted  POR 
to  provide  this  capability. 
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One  of  the  key  ideas  in  this  vision  is  leveraging  the  capability  in  CPOF 
to  which  the  soldiers  in  the  field  consistently  give  high  marks— ease  of  use 
and  ease  of  training.  This  common  platform  provides  a  consistent  map  and 
set  of  graphics,  greatly  enhancing  interoperability. 


Reducing  Risk 

All  of  the  above— the  experimentation  in-theater,  spiral  development, 
and  development  of  the  vision  for  the  future— was  done  in  parallel.  The 
goal  of  all  of  this  was  to  get  the  fullest  capability  to  the  soldier  rapidly, 
while  laying  the  groundwork  for  future  development— all  while  reducing 
program  risk. 


RISK  MANAGEMENT 

Risk  management  was  one  of  the  major  project  management  tools 
for  CPOF  development,  test,  and  fielding.  The  CPOF  effort  is  continuously 
evaluated  to  determine  exposure  to  risk  and  how  to  best  handle  such 
exposure.  Specifically,  the  risk  management  aspect  of  the  CPOF  aims 
to  allow  CPOF  to  be  fielded  to  the  user  community  with  as  many  risks 
identified,  mitigated,  or  categorized  as  acceptable,  as  possible  (Thomas 
&  Cook,  2005). 

The  Product  Manager,  Tactical  Battle  Command  (responsible  for 
CPOF),  and  the  contracted  development  team  are  both  responsible  for 
performing  risk  management  activities.  The  contractor  is  responsible 
for  assigning  appropriate  parties  and/or  organizations  for  enforcing  and 
performing  risk  management  activities. 

An  example  of  a  risk  matrix  is  shown  in  Figure  4.  It  identifies  risks, 
categorizes  them,  and  suggests  possible  mitigation.  One  of  the  things  that 
makes  this  management  tool  so  effective  is  that  the  risks  and  possible 
mitigation  paths  are  publicly  discussed.  In  this  way,  the  entire  community 
comes  to  a  similar  understanding  of  the  capabilities  and  limitations  of  the 
product.  The  acquisition  strategy  was  directly  tied  to  the  risk  analysis.  The 
events  and  decisions  were  based  on  the  identified  risks.  Major  risk  areas 
identified  were: 

•  Scalability 

•  Interoperability 

•  Supportability 

•  Full-Spectrum  Operations 

•  Architecture 
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FIGURE  4.  RISK  MATRIX 


Category  Risk  (RIN) 


Supportability 

(Low/Moderate) 


FSR  Support 

•  Ability  to  support  full  Army  fielding  IAW 
PM  Support  concept  (multifunctional 
FSRs) 

•  Stovepipe  support  structure 

•  Incorporation  of  FSR  Experience  Into 
Design  Process 

•  Downsizing  of  FSR  Personnel 


Mitigation  (Handling) 


Simplify/Stabilize  SW 
Automate  maintenance  function 
Cross-functional  FSRs  across  BC 
Dev  existing  BC  support  base  for  CPOF 
Integrate  into  the  Army  Support  Structure 


Metric  (Monitoring) 


FSR/Unit  (DIV/BDE/BN.  etc) 

Data  Integration  for  Reporting  and  Reuse 


Risk  Status 


The  System  of  System  (SoS)  Migration  Plan 
Implementation  and  the  mandated  FSR  reduction 
requirement  for  FY08  drives  this  risk. 


Risk  Assessment 


Software  Supportability/Efficiency 

•  Ability  for  CPOF  software  to  aid  in  and 
provide  a  Stable  CPOF  Network 

•  Ability  for  CPOF  to  be  upgraded  and  fixed 
as  needed,  on  the  fly  and  from  a  remote 
location. 

•  SW  Documentation 

•  CM  Processes 

•  Garbage  Collection 

«  64  Bit  Backup  Processes 


Deploying  'SuperTech'  developer  to  theater 
Implementation  of  Development  Crisis  Team 
Develop  remote  admin  and  distribution  capabilities 


Computer  Resource  Utilization/Available 

SW  Quality  Level 

Used  Standards  Metric 

Reliability  (Fault  Tolerance,  recoverability) 

Maintainability  (Stability,  changeability) 

Operational  Ability  (Ao) 


Current  development  tasks  are  designed  to  increase 
the  ability  of  the  baseline  3.0.2  Software  to  aid  in 
the  supportability  area.  Development  remains  on 
track  but  the  technical  difficulty  of  implementation 
drives  this  risk  to  be  moderate. 


Hardware  Support  &  Acquisition  Processes 

•  Hardware  Availability  and  Lead  Time  to 
support  on-going  ops 

•  End  of  Life 

•  Maintain  multiple  configurations 


Buffer  Supply  of  hardware  to  deploy  as  needed 
Leave  behind  hardware  in  Theater  for  next  units  to 
fall  in  on 

Use  Spares  to  fill  in  gaps  until  hardware  arrives 
UID 

CM  Process,  Documentation  and  Enforcement 


Estimated  vs.  Actual  Delivery  Times 
Maintenance  Downtime 
Repair  Cycle  Time 
Parts  Availability 


Contact  Is  in  place  for  the  acquisition  of  hardware 
and  support.  The  implementation  of  a  Configuration 
Management  process  will  be  in  place  by  FY07  thus 
helping  reduce  the  risk. 


Training 

•  Training  structures  integrated  into 
mainstream  Battle  Command  Support 
Structures 


Inclusion  of  an  embedded  trainer. 

Training  and  Support  package  for  NET,  TRADOC 
and  Sustainment 


Actual  vs.  Planned  #  of  personnel  attending 
Training  Systems  Available 
Student  Proficiency  /Skill  Level 
Training  Level  vs.  Proficiency 


Logistics  Products  are  currently  being  developed  to 
improve  current  training  and  to  meet  the  First  Unit 
Equipped  Date  (FUED). 
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Technical 

(Moderate) 


incompatible  Versions  of  Fielded  Software 
Bug  Fixes  and  Patch  Upgrades 
Inadequate  Evaluation  of  SW 


Implementation  of  Multiple  CPOF  Networks 
PASS  to  Exchange  Information 
Field  New  Units  CONUS 

Evaluate  and  Determine  Criticality  of  Bug  Fixes 
and  Patches.  If  possible  Roll  Up  to  decrease  system 
upgrade  times. 

Remote  Admin  push  of  small  critical  updates 


#  and  Version  Type  of  CPOF  Networks 
tt  of  Total  SW  Bugs  vs.  #  Critical  SW  Bugs 
Percentage  of  Total  Critical  Bugs  Fixed 


Currently,  Bugs  are  identified,  evaluated  and  rolled 
up  into  fixes  and  patches  based  on  prime  ’s 
processes.  New  implementation  calls  for  GOV 
approval  and  structuring  of  Patches,  Fixes  and 
Smaller  Releases  to  allow  for  identification  of 
critical  elements  and  establishment  of  acceptable 
timeframes. 


Current  Software  Limitations 
No  Full  spectrum  Ops 
No  Ruggedization 
Limited  Interoperability 
Theater  Requested  Enhancements 
Marine  Requested  Enhancements 


Expectation  Management 
Customer  Awareness 

Evaluate  and  Implement  Important  Theater/ 

Marine  Requests  using  out  Quick  Reaction  Theater 
Development  Support  and  Prime  SW  Development 
Team 


ft  Theater/Marine  Requests  Outstanding 
Average  Implementation  Time  of  Theater/Marine 
Requests 


Currently  CPOF  Block  2  Requirements  do  not 
provide  complete  Full  Spectrum  Capability  to 
the  Warfighter.  Currently  effective  customer 
management  by  PO  and  FSR  Personnel  help  to  give 
Customers  an  understanding  of  when  capability 
will  become  available.  Most  new  requirements  are 
processed  and  approved  by  the  TSM. 
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Specific  tasks  to  address  these  risks  have  been  developed  and 
crosswalked  with  the  TRADOC  Capabilities  Manager  (TCM)-developed 
requirement.  Then  these  requirements  are  balanced  with  the  expected 
resource  availability  to  develop  the  build  plan. 

Risk  assessments  were  done  in  parallel  with  the  early  DARPA 
development.  It  was  clear  that  CPOF,  while  providing  needed  capability 
in-theater,  needed  work  to  become  “productized.”  Risks  to  the  program- 
technical  and  programmatic— were  identified.  Then  mitigation  plans  were 
developed  openly  for  each  risk.  This  in-theater  feedback  loop— shortfalls 
identified,  fed  back  into  the  risk  plan,  mitigated,  and  fixes  sent  back  in¬ 
theater— allowed  incrementally  better  product  to  get  into  the  soldiers' 
hands  quickly. 


TAILORING  ACQUISITION  STRATEGY  TO  ACCEPT  THE  NEW  TECHNOLOGY 
USING  A  SPIRAL  PROCESS 

The  standard  DoD  5000  acquisition  strategy  was  tailored  specifically 
to  allow  the  new  CPOF  technology  to  make  it  to  the  field  sooner  rather 
than  later.  It  was  also  tailored  so  that  CPOF  could  be  incorporated  as  a 
technology  insertion  into  the  ABCS  System  of  Systems. 

The  acquisition  strategy  was  specifically  designed  around  mitigating 
risks.  An  honest  risk  assessment  was  the  first  step— do  the  analysis  of 
CPOF’s  shortfalls  and  put  mitigation  plans  in  place  for  each  identified 
risk.  The  development  tasks  fell  out  of  the  mitigation  plans.  For  example, 
one  risk  was  scalability  in-theater;  i.e.,  moving  from  200  users  to  more 
than  1,000  users.  The  mitigation  plan  noted  that  the  server  architecture 


FIGURE  5.  ACQUISITION  DECISION  FLOW  CHART 
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'Based  on  4th  Infantry  Division  Mission  Rehearsal  Exercise  (MRX)  (29  Jul-4  Aug), 
1st  Brigade  Combat  Team  National  Training  Center  Rotation  (6  Sep-4  Oct)  (and  the 
3rd  infantry  Division  Full  Operational  Assessment  Hi  in-theater— Tentative) 


17 


A  Publication  of  the  Defense  Acquisition  University 


www.dau.mi 


would  not  support  that  many  clients  (users).  The  redesign  of  the  server 
architecture  to  add  mid-tier  servers  was  a  key  development  task.  The 
strategy  was  developed  to  fix  the  risks  over  time,  rather  than  trying  to 
develop  the  perfect  product  in  one  delivery. 

The  Acquisition  Decision  Flow  Chart  is  shown  in  Figure  5.  It  shows 
two  decision  points  (DP)  where  leadership  had  the  opportunity  to  review 
the  progress  of  the  program  and  to  decide  if  the  program  was  ready  to 
move  forward  as  planned.  Each  of  these  decision  points  was  linked  to  an 
event  that  could  be  used  to  demonstrate  whether  or  not  CPOF  was  ready 
to  move  ahead.  These  decision  points  enabled  the  leadership  to  evaluate 
program  risk  to  determine  the  best  path  forward. 

The  acquisition  strategy  included  two  key  decision  points  as  shown 
in  Figure  5.  These  were  selected  in  advance  at  junctures  in  the  program 
where  go/no  go-type  decisions  could  be  made.  These  decision  points  were 
not  selected  based  on  schedules,  but  rather  on  whether  the  program  was 
capable  of  proceeding  to  the  next  step  in  the  acquisition  process,  i.e.,  they 
demonstrated  readiness  for  transfer  and  reduction  of  risk.  Decision  Point 
1  (DPI)  was  held  to  determine  if  CPOF  had  met  the  transition  goals  for  the 
Army  to  accept  the  technology  from  DARPA.  DP2  was  a  Milestone  C-like 
event  to  determine  if  CPOF  was  capable  of  being  fielded  as  part  of  the 
software  block  to  the  entire  Army.  For  Decision  Point  2  (DP2),  a  brief  was 
given  to  the  community,  including  the  General  Officer  (GO)  leadership, 
showing  that  CPOF  had  the  capability,  certifications,  documentation,  and 
sustainment  capability  to  support  the  decision  for  fielding. 

The  CPOF  Addendum  to  the  MCS  Acquisition  Strategy  was  signed  by 
MG  Michael  R.  Mazzucchi,  USA  (Ret.),  in  July  2005. 

•  CPOF  is  a  technology  insertion  into  MCS,  which  was  in  full 
rate  production. 

•  To  ensure  that  DARPA  met  the  conditions  of  the  Army- 
DARPA  MOA  and  that  CPOF  was  performing  satisfactorily  in 
unit  operations,  the  Army  conducted  a  Level  I  Development 
Test  (DT)  event  and  a  series  of  Level  II  Operational 
Assessments  of  CPOF  in  fielded  units.  These  assessments 
provided  data  for  informed  decisions  at  DPI  and  DP2, 
respectively. 

•  DPI  was  conducted  in  March  2006,  and  documented  in 
the  PEO  C3T  DPI  ADM  dated  April  2006.  The  purpose  of 
this  decision  point  was  to  accept  transition  from  DARPA 
and  approve  Research,  Development,  Test,  &  Evaluation 
(RDT&E)  funding  to  reduce  risk  and  baseline/assess  the 
CPOF  system;  and  to  approve  Other  Procurement,  Army 
(OPA)  funding  to  support  theater  and  continental  United 
States  fielded  units.  DP2  included  a  CPOF  Block  li  Milestone 
C  to  determine  whether  the  current  block  of  software/ 
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hardware  was  suitable  for  fielding  in  accordance  with  the 
ABCS  6.4  schedule.  DP2  also  included  CPOF  Block  III 
Milestone  B  to  authorize  research,  development,  and  test 
activities  for  continued  CPOF  development. 

•  The  CPOF  acquisition  strategy  reflected  the  use  of 
innovative  solutions  and  utilized  best  practices  in  the 
following  aspects: 

O  Extensive  use  of  integrated  government-developed 
software  and  COTS  software 

O  Streamlined  acquisition  processes  wherever  appropriate 

•  Capability  is  to  be  provided  incrementally,  putting  the  best 
of  80  percent  solution  into  the  field  quickly. 

•  Contracting  Strategy 

O  Software— Software  development,  software 

maintenance,  fielding  support,  field  service  support, 
training,  and  documentation  were  procured  via  a  5-year 
sole  source  (i.e.,  a  1-year  basic  plus  four  1-year  options) 
basic  ordering  agreement  with  the  software  developer. 

Upon  attaining  a  successful  DP2,  task  orders  were 
awarded  on  an  annual  basis  as  required  to  support 
additional  fielding  of  the  baseline  CPOF  product  and 
related  activities. 

O  Hardware— Hardware  and  peripherals  to  support  CPOF 
fieldings  were  procured  via  award  of  task  orders  on  a 
competitively  awarded  hardware  ordering  contract. 

Hardware  procurement  included  a  5-year  warranty  for 
all  items. 

Design  and  Program  Reviews  were  also  scheduled  at  regular  intervals. 
These  gave  the  leadership  and  the  rest  of  the  community  an  opportunity 
to  evaluate  CPOF.  This  helped  ensure  that  CPOF  development  stayed  in 
sync  with  the  rest  of  the  Army  programs,  and  that  the  program  risk  was 
within  acceptable  limits.  The  acquisition  plan  also  specified  design  reviews. 
These  reviews  were  publicly  held  and  covered  technical,  programmatic, 
and  funding  issues.  They  were  intended  to  engage  the  community.  Again, 
the  philosophy  is  that  the  more  that  is  known  about  a  system's  capabilities 
and  limitations,  the  better  the  focus  that  can  be  brought  to  solve  issues. 
This  allows  a  more  capable,  useful  system  to  make  it  to  the  field. 
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Lessons  Learned:  Best  Practices  for  a  Successful  Transition 

Inserting  a  new  technology  into  an  existing  System  of  Systems  is  not 
a  straightforward  or  easy  task,  but  some  key  lessons  were  learned  during 
the  CPOF  transition. 


LEADERSHIP 

Leadership  of  both  the  technology  provider  and  the  receiver  must 
be  fully  engaged  and  supportive.  The  MOA  helped  ease  the  transition  by 
providing  a  2-year  window,  along  with  adequate  funding,  for  the  DARPA 
and  Army  teams  to  collaborate  on  how  best  to  grow  CPOF  into  a  fielded 
system  used  by  soldiers  every  day. 


VISION 

A  vision,  both  near-term  and  long-term,  greatly  helps  in  both 
acquisition  and  technical  issues.  The  vision  to  use  CPOF  as  the  common 
platform  for  collaborative  services  has  stretched  the  original  system  to  fill 
gaps  left  by  the  other  ABCS  system  of  systems.  The  vision  provides  the 
framework  for  breaking  large  strategic  goals  into  smaller,  more  executable 
ones.  It  also  helps  prioritize  efforts. 


EXPERIMENTATION 

Experimentation  is  needed  in  developing  a  successful  product. 
Exposing  ideas  to  actual  (vs.  laboratory)  conditions  changes  the  way 
designers  and  developers  view  the  system.  Many  improvements  to 
CPOF  were  made  because  the  system  was  deployed  in-theater  so  early 
in  its  development  cycle.  Even  after  CPOF  was  integrated  into  the  ABCS 
system  of  systems  and  had  scaled  to  over  5,000  systems,  experimentation 
continues.  A  concerted  effort  is  underway  to  continually  solicit  and 
incorporate  all  user  feedback  into  the  system  to  make  it  relevant  to  the 
current  fight.  Experimentation  must  involve  the  user  up  front  and  early 
with  a  tight  feedback  loop  with  the  developer. 


EVENT-DRIVEN  PROCESS 

The  spiral  process  used  to  insert  CPOF  into  the  ABCS  POR  was  a 
tailored  DoD  5000  process.  It  was  event-driven,  using  regular,  scheduled 
decision  points  to  proceed.  At  each,  the  system  was  honestly  evaluated  to 
determine  progress  and  to  steer  towards  the  optimal  path  forward. 
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MANAGING  CHANGE 

Any  new  system  or  technology  will  require  changes  or  adjustments 
once  exposed  to  real-world  conditions.  CPOF,  in  the  years  that  it  has 
been  in  the  field,  has  changed  significantly.  It  has  been  scaled  up  from 
just  a  handful  of  systems  and  now  interfaces  directly  into  ABCS.  CPOF 
is  an  official  part  of  the  LandWarNet  (LWN)/G3  software  baselines  that 
are  fielded  to  Army.  This  has  only  been  possible  because  all  parties  have 
embraced  the  new  technology  and  worked  hard  to  incorporate  it  and 
tailor  it  to  best  advantage.  Accepting  and  managing  the  change  have 
made  this  possible! 


COMMUNITY  RISKS 

Most  importantly,  communicating  risks  and  issues  in  an  open,  honest 
way  helped  manage  expectations  of  soldiers,  leadership,  and  technologists. 
Regular  risk  assessment  and  mitigation  discussions  at  all  levels  helped 
focus  resources  where  they  were  needed  most.  For  example,  one  early 
technical  risk  was  the  concern  about  how  the  CPOF  network  would  scale 
in-theater.  The  mitigation  for  this  risk,  which  was  actually  executed,  was  to 
incrementally  grow  the  network  in-theater.  This  was  successful  and  allowed 
the  users  and  technical  support  to  address  smaller  issues  as  they  occurred. 


Conclusions 

The  transition  of  CPOF  from  DARPA  to  the  U.S.  Army  was  successful 
for  a  number  of  reasons.  Tailoring  the  DoD  5000  acquisition  strategy 
allowed  new  CPOF  technology  to  be  fielded  as  a  technology  insertion 
into  the  ABCS.  The  keys  to  this  successful  transition  can  be  linked  to  the 
efficient  use  of  risk  management  techniques  to  drive  the  program  forward, 
use  of  early  and  sustained  feedback  from  the  user  community,  maintaining 
transition  funding  stability,  and  honest  and  open  communication  between 
all  stakeholders. 
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LEAD  SYSTEMS 
INTEGRATORS: 

A  POST-ACQUISITION 
REFORM  RETROSPECTIVE 


i  Kathlyn  Hopkins  Loud  in 

This  article  explores  concerns  about  the  mid-1990s  Acquisi¬ 
tion  Reform  notion  of  partnering  with  industry.  Design  Agent, 
Lead  Systems  Integrator,  and  Total  System  Performance 
Responsibility  roles  were  conveyed  to  companies  charged 
with  system  design,  technology  development,  and  funds 
allocation,  while  balancing  cost,  schedule,  and  performance 
goals  for  program  success.  Although  these  arrangements 
arose  from  noble  intentions,  recent  critics  have  posited  that 
they  have  driven  cost  growth  and  have  weakened  DoD's 
ability  to  coordinate  and  control  acquisition  programs.  The 
author  infused  real-world  phenomena  with  elements  of 
economic  transaction  cost  theory  and  network  theory  to 
make  recommendations  about  future  optimization  of  roles. 


Keywords:  Acquisition  Reform,  Cost  Growth,  Industry, 
Design  Agent,  Lead  Systems  integrator  (LSI),  Total 
System  Performance  Responsibility  (TSPR) 
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Multibillion-dollar  acquisition  challenges,  such  as  those  confronted  by 
the  Navy’s  Littoral  Combat  Ship  program  and  the  Army’s  Future  Combat 
System,  have  sharpened  public  focus  on  the  Department  of  Defense 
(DoD)’s  ability  to  manage  programs  and  control  costs.  This  has  triggered 
concerns  about  initiatives  brought  into  vogue  more  than  10  years  ago, 
prompted  by  mid-1990s  Acquisition  Reform-type  thinking  about  fresh 
environments  in  which  efficiency  and  effectiveness  can  flourish. 

One  such  notion  from  that  era  embraced  the  philosophy  of  “partnering 
with  industry.”  Titles  such  as  Design  Agent,  Lead  Systems  Integrator,  and 
Total  System  Performance  Responsibility  were  bestowed  upon  private 
companies  entrusted  with  broader,  more  influential  roles  than  ever  before. 
These  involved  system  design,  technology  development,  acquisition,  and 
funds  allocation— all  the  while  balancing  cost,  schedule,  and  performance 
goals  to  ensure  program  success. 


Acquisition  Reform  in  Retrospect 

Acquisition  is  among  the  most  "reviled,  reviewed,  and  reformed” 
activities  of  government  (Besselman,  Arora,  &  Larkey,  2000,  p.  423).  With 
more  than  $314  billion  at  stake  annually  (GAO,  2008),  DoD  programs 
understandably  attract  scrutiny.  Ideological  changes  come  with  new 
Presidential  administrations  and  prompt  policy  swings,  often  from  one 
extreme  to  another.  Linder  the  Obama  Administration,  the  recently  signed 
Weapon  Systems  Acquisition  Report  Act  of  2009  aims  to  bolster  DoD’s 
workforce,  increasing  systems  engineering  and  program  oversight. 

In  contrast,  the  mid-1990s  vision  of  Acquisition  Reform  aimed  at 
achieving  efficiencies.  Diminishing  post-Cold  War  budget  realities  led  to 
the  Federal  Acquisition  Streamlining  Act  of  1994;  this  was  advanced  by 
subsequent  legislation.  DoD  implemented  the  Clinger-Cohen  Act  of  1996, 
the  Federal  Acquisition  Reform  Act  of  1995,  and  the  Government  Results 
and  Performance  Act  of  1993  in  accordance  with  Office  of  Management 
and  Budget  (OMB)  Circulars  A-130  and  A-11.  One  key  assumption  of  these 
reforms  was  that  cost  efficiency  could  be  improved  by  using  contractors 
more  effectively— sometimes  in  more  powerful  roles  than  ever  before. 


Background 

Within  the  military  services,  different  terms  are  used  to  describe  this 
business  arrangement.  “Lead  Systems  Integrator”  (LSI)  appears  across 
the  Services,  but  is  most  heavily  used  by  the  Army.  The  LSI  concept 
was  first  manifested  in  a  1997  contract  with  Boeing  for  National  Missile 
Defense,  a  complex  system  of  systems.  Boeing’s  scope  transcended 
that  of  a  typical  prime  contractor.  It  involved  concept  definition,  overall 
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systems  engineering  and  integration,  and  leadership  of  Integrated  Product 
Teams  (IPTs).  According  to  Gholz  (2004),  subsequent  LSI  contracts  were 
awarded  to  Boeing  for  essentially  masterminding  equipment  vital  to  future 
operational  capability.  Similarly  great  expectations  were  conveyed  to  the 
Boeing-Science  Applications  International  Corporation  (SAIC)  team  on 
Future  Combat  Systems  (FCS). 

Within  the  Navy,  “Design  Agent”  connotes  responsibility  for 
systems  design  and  development.  This  entails  generating  requirements, 
developing  technology,  leading  systems  integration,  allocating  resources 
on  behalf  of  the  customer,  managing  supply  chains,  and  conducting 
testing  and  validation— sometimes  all  the  way  through  Low  Rate  Initial 
Production  (LRIP).  The  Navy  sometimes  uses  "Design  Agent”  and  “LSI” 
interchangeably. 

Within  the  Air  Force,  “Total  System  Performance  Responsibility” 
(TSPR)  emerged  in  contract  clauses  in  the  1970s.  In  1999,  the  Air  Force 
chartered  a  TSPR  working  group,  whose  recommendations  led  to 
certain  contractors  taking  responsibility  for  design,  configuration,  and 
requirements  solutions,  as  well  as  accountability  for  fielded  systems. 
White  (2001)  characterizes  TSPR  as  encompassing:  (1)  integration  of 
the  aircraft,  its  subsystems,  and  all  components  (hardware,  software, 
data),  whether  provided  as  Government  Furnished  Property  (GFP)  or 
acquired  commercially,  and  (2)  assurance  that  the  system  will  meet 
specifications.  Example  programs  include  the  F-117  and  the  Space-Based 
Infrared  System  High. 

Irrespective  of  nomenclature  differences,  by  the  late  1990s,  the 
Services  had  begun  to  shift  more  development  and  systems  engineering 
work  to  the  private  sector.  Under  traditional  acquisition  strategies, 
DoD  procured  various  weapons,  components,  and  platforms,  and  then 
combined  and  refined  them,  eventually  achieving  operational  capability. 
Influenced  heavily  by  the  post-Cold  War  “peace  dividend”  aimed  at 
reducing  spending  on  procurements,  facilities,  and  people,  however,  new 
strategies  called  for  DoD’s  issuance  of  a  Statement  of  Objectives  (SOO). 
Then  qualified  industry  partners  could  derive  technical  specifications 
and  determine  how  to  allocate  Research  and  Development  (R&D)  and 
procurement  funds.  This  was  predicated  on  the  notion  that  industry 
possessed  the  broad  technical  and  programmatic  knowledge  needed 
to  meet  cost,  schedule,  and  performance  objectives— and  was  strongly 
motivated  to  do  just  that. 

Although  this  model  was  favored  for  its  consistency  with  business 
transformation  efforts,  it  drew  criticism.  For  instance,  the  Defense  Science 
Board  (2002)  assessed  systemic  causes  of  cost  overruns,  schedule 
slippages,  and  capability  shortfalls,  and  pointed  to  a  “hollowing  out”  of 
organic  systems  engineering  capability  within  DoD.  Others  voiced  concerns 
over  the  increasingly  blurred  lines  between  government  and  industry. 
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Blurring  the  Lines:  Partners  and  Primes 

When  contractors  are  enlisted  to  work  in  ways  that  depart  from 
tradition,  organizational  roles  require  redefinition.  Rainey  (2003)  extended 
the  typology  by  categorizing  different  economic  sectors  not  merely 
as  public  or  private,  but  as  mixed,  intermediate,  or  hybrid,  noting  that 
many  private,  for-profit  companies  work  with  government  in  ways  that 
transcend  normal  boundaries.  For  example,  early  news  releases  for  the 
FCS  team  touted  Boeing  and  SAIC  not  as  contractors,  but  as  full-fledged 
government  partners. 

While  the  idea  of  productive  public-private  partnerships  is  appealing, 
lines  of  demarcation  between  "inherently  governmental”  and  "commercial” 
activities  need  to  be  thoroughly  understood.  Circular  A-76,  published  by 
the  Office  of  Management  and  Budget  (OMB,  2003),  states: 

An  inherently  governmental  activity  involves:  (1)  Binding  the 
United  States  to  take  or  not  to  take  some  action  by  contract,  policy, 
regulation,  authorization,  order,  or  otherwise;  (2)  Determining, 
protecting,  and  advancing  economic,  political,  territorial,  property, 
or  other  interests  by  military  or  diplomatic  action,  civil  or  criminal 
judicial  proceedings,  contract  management,  or  otherwise;  (3) 
Significantly  affecting  the  life,  liberty,  or  property  of  private 
persons;  or  (4)  Exerting  ultimate  control  over  the  acquisition,  use, 
or  disposition  of  United  States  property,  [including]  collection, 
control,  or  disbursement  of  appropriated  and  other  federal  funds, 
(p.  A-2) 

OMB  Circular  A-76  does  permit  private  firms  to  engage  in  activities 
involving  discretion,  provided  that  the  firm  holds  no  decision-making 
authority,  but  instead  develops  options  and  implements  actions  under 
government  supervision.  Similarly,  under  the  2008  National  Defense 
Authorization  Act  (NDAA),  DoD  may  contract  for  acquisition  support  on 
major  systems  development  and  production,  provided  that  the  contractor 
performs  no  inherently  governmental  functions  and  makes  no  decisions 
on  technical  performance.  The  2009  NDAA  calls  for  policy  standardization 
on  inherently  governmental  functions  and  potential  conflicts  of  interest. 

Therein  lies  the  challenge,  of  course:  Consistent  policy  implementation 
is  difficult  under  the  best  of  conditions.  It  is  daunting  in  highly  complex, 
high-dollar  acquisitions  involving  systems  of  systems.  Numerous  analysts 
have  sounded  alarms  over  the  “hollow  state,”  or  its  inability  to  convey 
sound  technical  direction  to  contractors  (Crawford  &  Krahn,  1998;  Kettl, 
1988;  Milward,  1996).  This  often  culminates  in  cost  overruns,  performance 
problems,  and  recurring  ambiguity  regarding  responsibilities. 

Concern  over  casting  contractors  in  non-traditional,  influential  roles 
had  escalated  by  2007.  Then-Secretary  of  the  Navy  Donald  Winter  voiced 
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discontent  with  current  business  practices,  stressing  the  erosion  of 
engineering  expertise  within  the  Navy  and  over  reliance  upon  contractors. 
He  also  criticized  the  Pentagon  for  its  failure  to  understand  competitive 
pressures  and  Wall  Street  expectations.  Winter’s  speech,  delivered 
while  the  Navy  was  renegotiating  its  Littoral  Combat  Ship  contract  with 
Lockheed  Martin,  stressed  that  the  LSI  should  be  a  DoD  entity,  not  a 
contractor  (Castelli,  2007). 

The  2008  NDAA  contained  language  barring  the  award  of  new 
LSI  contracts  after  FY  2010;  with  few  exceptions,  it  prohibited  such 
arrangements  for  programs  beyond  LRIP.  The  NDAA  for  2009  specifically 
forbids  the  award  of  an  LSI  contract  for  LRIP  or  full-rate  production  of 
major  elements  of  the  FCS  program.  Given  these  stipulations,  it  is  clear 
that  partnerships  with  industry,  once  believed  to  boost  efficiency  and 
effectiveness,  are  now  destined  for  the  history  books. 


Review  of  the  Literature 

The  author  found  few  quantitative  analyses  of  Design  Agent,  LSI,  or 
TSPR  arrangements;  most  were  qualitative  in  nature.  White  (2001),  for 
example,  assessed  the  value  of  TSPR  in  Air  Force  acquisition  strategies 
using  multiple  case  studies  and  self-reported  data.  White  reported  that 
one  program  office  realized  $1.2  billion  in  cost  savings  over  a  10-year 
period;  they  cited  manpower  reductions,  competition,  and  contractor 
innovations,  but  provided  no  substantiation.  Still,  White  concluded  that 
TSPR  arrangements  could  produce  cost  savings,  but  stated  that  TSPR 
impact  on  program  performance  remained  unclear. 

Flood  and  Richard  (2005)  authored  a  qualitative  study  of  the  LSI 
experience  of  the  Army  FCS  program.  They  compared  the  LSI  model 
to  DoD’s  traditional  program  office  model,  weighed  the  pros  and  the 
cons  of  each  arrangement,  and  suggested  strengthening  processes, 
clearly  defining  program  objectives,  and  instituting  a  success-oriented 
culture.  Similarly,  Gholz  (2004)  presented  a  qualitative  assessment  of 
LSI  arrangements,  cautioning  governments  against  over-centralization 
of  acquisition  activities.  Gholz  also  warned  against  possible  abdication 
of  leadership  responsibility  and  the  atrophying  of  the  government’s 
technical  competency. 

Considering  alternative  DoD  acquisition  arrangements  more  broadly, 
other  studies  have  endeavored  to  augment  qualitative  data  with  numbers. 
In  an  examination  of  Defense  Acquisition  Pilot  Programs  (DAPPs),  Reig 
(2000)  baselined  the  initial  state,  identified  changes,  and  measured 
their  impact.  Reig  combined  cost  and  schedule  metrics  from  Selected 
Acquisition  Reports  (SARs)  with  performance  data  from  test  reports  of 
Acquisition  Category  (ACAT)  I  programs  prior  to  Acquisition  Reform.  He 
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contended  that  DAPPs  could  not  be  meaningfully  compared  to  "standard” 
programs  unless  they  were  developed  contemporaneously. 

Literature  on  the  general  contracting-out  debate  was  abundant; 
some  of  it  delved  into  the  quantitative.  Globerman  &  Vining  (1996) 
attempted  to  calculate  the  cost  of  contracting  out.  The  Government 
Accountability  Office  (GAO)  has  conducted  numerous  cost  comparisons, 
but  reported  in  2008  that  data  are  generally  inconclusive.  GAO  (2007) 
reported  that,  although  DoD  maintains  data  from  competitive  sourcing 
(i.e.,  A-76)  efforts,  the  number  of  competitions  is  small,  and  results  may 
not  be  generalizable.  Other  studies  include  Smith  &  Smyth  (1996),  who 
addressed  accountability  in  contracting,  and  Miles  and  Snow  (1992),  who 
identified  drawbacks  to  contracting  out.  Goodsell  (2007)  referred  to  the 
Constitution’s  preamble  for  determining  what  is  inherently  governmental. 
Kelman  (2007),  formerly  head  of  Office  of  Federal  Procurement  Policy, 
published  a  treatise  on  astute  contract  management  to  combat  cost 
overruns  and  performance  failures. 

Finally,  literature  on  the  “demanding  customer”  and  the  implications 
of  “hollow”  organizations  (Crawford  &  Krahn,  1998)  tied  empirical  data 
to  theory.  Frederickson  and  Frederickson  (2000)  contributed  to  network 
theory  by  articulating  an  array  of  engagements  among  entities,  including 
formal  contracts,  grants,  regulations,  and  other  transactions;  their  work 
was  qualitative  in  nature.  The  preponderance  of  qualitative  work  is  not 
surprising,  given  problems  with  gathering,  normalizing,  and  interpreting 
quantitative  data,  particularly  public-domain  data. 


METHODOLOGY  1:  QUANTITATIVE  ANALYSIS 

To  gauge  the  prevalence  and  dollar  value  of  LSI-like  contracts,  the 
author  conducted  a  keyword  search  within  DoD’s  public  archives  (DoD, 
2009b)  to  find  all  contracting  actions  valued  at  more  than  $5  million 
between  October  1994  through  March  2008.  Keywords  used  were  “Design 
Agent”  or  “Lead  System(s)  Integrator”  or  “Lead  System(s)  Integration." 
Dozens  of  contracting  actions  were  found:  Their  values  ranged  from  $5 
million  to  $2,879  billion. 

The  figure  shown  here  reflects  trends  that  can  be  detected  from 
the  data.  First,  soon  after  Acquisition  Reform,  the  number  of  LSI-like 
contracting  actions  ascended,  reflecting  an  initial  burst  of  activity 
consistent  with  new  policies.  With  the  turn  of  the  century  came  a  leveling 
off;  this  could  indicate  a  time  of  policy  analysis  and  program  evaluation. 
Then  during  2002—2004,  the  number  of  actions  reached  a  new  peak.  Their 
dollar  values  increased,  as  well.  The  Navy  contracted  for  billions  of  dollars 
of  support  to  then-DD(X)  and  nuclear  submarine  programs.  After  2004, 
the  purity  of  LSI-like  contracts  became  increasingly  suspect,  as  hybrid 
contracts  for  design  and  maintenance  emerged.  By  2007,  the  popularity 
of  LSI-like  efforts  declined;  this  is  consistent  with  DoD’s  changing  stance 
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FIGURE.  PREVALENCE  OF  LSI-TYPE  CONTRACTS  OVER  TIME, 
1994-2008 
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on  acquisition  strategies.  (The  2008  legislation  on  phasing  out  contractor- 
as-LSI  arrangements  was  preceded  by  several  years  of  intense  scrutiny  by 
the  GAO,  the  Congressional  Research  Service,  and  others.) 

The  author  acknowledges  limitations  to  the  data.  First,  nomenclature 
used  in  contract  announcements  was  inconsistent.  Several  news  items 
indicated  that  "Design  Agents”  were  being  used  for  maintenance  on  an 
aging  class  of  ships.  Other  contracts  that  were  clearly  LSI  in  nature  lacked 
those  keywords.  Therefore,  some  work  is  counted  too  heavily  and  some  is 
not  counted  at  all:  It  is  difficult  to  gauge  the  extent  to  which  these  factors 
offset  one  another.  Secondly,  attempts  to  assign  values  to  actions  were 
complicated  by  the  fact  that  only  Contract  Line  Item  Number  (CLIN) 
ceiling  amounts  were  reported.  In  cost-plus  contracting,  CLIN  ceilings 
may  or  may  not  have  been  fully  funded.  Valuation  of  LSI-type  scope  as 
a  subset  of  the  overall  contract  value  was  problematical  as  well,  given 
limited  public  information. 

Still,  having  traced  the  general  build-up  and  demise  of  non-traditional 
arrangements,  the  author  attempted  to  compare  the  acquisition  costs 
and  performance  effectiveness  of  contractor-led  acquisition  programs 
to  those  of  government-led  acquisition  programs  of  similar  scope.  This 
was  complicated  by  issues  identified  by  Reig  (2000):  Contractor-led 
programs  came  into  vogue  during  a  period  of  time  when  few  comparable 
government-led  programs  were  at  the  same  stage  of  development. 
Organizational  culture  and  interorganizational  relationships— both  time- 
sensitive— can  also  influence  cost  savings  and  performance.  Thus,  it 
is  unfair  to  pit  a  pre-1990s  government-led  effort  against  a  post-1990s 
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contractor-led  effort.  Moreover,  other  aspects  of  post-Acquisition  Reform 
culture  converged  during  this  timeframe.  The  government  adopted  more 
commercial-like  practices,  and  other  innovations  such  as  Prime  Vendor 
Support  strategies  were  tested. 

For  these  reasons  and  others,  it  is  difficult  to  isolate  the  LSI  variable 
and  gauge  its  impact  on  cost  and  performance.  Other  issues  include:  (a) 
lack  of  commonality  in  contractor  cost  estimating  and  contractor  cost 
reporting  requirements,  (b)  lack  of  completeness  in  cost  and  pricing  data, 
(c)  the  dynamic  nature  of  government  cost  estimates,  and  (d)  limitations 
inherent  to  public-domain  data. 

In  complex  system-of-systems  efforts  involving  numerous  entities, 
cost  and  performance  data  are  clouded  by  commonality  issues.  First, 
firms  differ  in  their  accounting  systems;  cost  categorizations  vary. 
Although  major  DoD  contractors  must  obtain  approval  of  their  accounting 
systems  from  the  Defense  Contract  Management  Agency  (DCMA),  there 
is  no  single  “right  way”  to  report  subcontractor  labor  and  material  costs, 
to  differentiate  direct  from  indirect  costs,  or  to  draw  the  line  between 
recurring  and  non-recurring  costs.  Secondly,  cost-reporting  requirements 
vary  by  contract:  Lower-tier  vendors  tend  to  provide  basic  components 
and  services,  often  via  fixed-price  contracts.  Subcontractors  higher  in  the 
chain  tend  to  deliver  more  complex  services;  these  are  often  contracted 
via  cost-plus  vehicles.  Cost-plus  contracts  generally  call  for  more  cost¬ 
reporting  detail  than  do  fixed-price  contracts. 

Data-completeness  issues  arise  when  costs  are  captured  and  reported 
via  multiple  contracts.  When  programs  extend  over  years  or  decades, 
the  clarity  and  completeness  of  cost  data  are  clouded  when  performing 
entities  change,  whether  via  corporate  reorganization  or  recompetition. 
Additionally,  valid  comparisons  of  contractor- led  efforts  to  DoD- led  efforts 
require  the  inclusion  of  government  costs  that  are  not  often  quantified. 
For  instance,  DoD  “overhead”  costs,  such  as  the  contracting  office, 
are  commonly  overlooked  in  make-or-buy  decisions.  (Since  overhead 
functions  are  reflected  in  an  agency’s  cost  structure  whether  or  not 
services  are  used,  they  are  often  viewed  as  cost-neutral.)  This  tendency 
may  be  changing,  however,  since  the  Accountability  in  Contracting  Act  of 
2007  calls  for  fully  burdened  costs  when  comparing  internal  sourcing  to 
contracting  out  (Lumsden,  2007). 

Other  obstacles  to  the  quantitative  analysis  of  alternative  strategies 
stem  from  the  temporal  nature  of  cost  estimates  and  budgets  for 
complex,  long-duration  efforts.  Cost  estimates  for  major  programs  reflect 
production  quantities,  schedules,  and  efficiencies  ostensibly  gained  with 
experience.  Over  time,  these  tend  to  change.  Over  long  periods  of  time, 
they  change  markedly.  The  researcher  also  found  differences  among 
budget  figures  (DoD,  2009b).  When  comparing  budget  exhibits  for  the 
Navy’s  Cooperative  Engagement  Capability  system,  figures  differed 
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sharply  among  programs.  This  is  likely  due  to  differing  assumptions  and 
cost-sharing  arrangements  negotiated  by  the  various  program  offices. 

Further  research  is  needed  to  illuminate  the  public-domain  data. 
Personal  interviews  with  program  staff,  as  well  as  with  DCMA,  can  provide 
insight  for  DoD  in  managing  acquisition  more  astutely. 

GAO  (2005)  confirmed  that,  while  differences  in  magnitude  and 
sources  of  cost  growth  exist,  all  shipbuilding  programs  experienced 
cost  growth  (Table  1).  Programmatics  (e.g.,  design  challenges,  schedule 
delays,  business  projections,  and  workforce  issues)  triggered  the  growth. 
Of  the  programs  studied,  the  Virginia  class  of  submarines  was  most 
closely  aligned  with  the  LSI  model.  GAO  concluded  that  its  cost  growth 
was  greater  than  that  for  some  Navy-led  programs,  but  less  than  that  for 
other  Navy-led  programs.  It  can  be  inferred  that  LSI-like  strategies,  taken 
alone,  are  not  good  predictors  of  cost  growth.  Interrelated  rival  causes  are 
detailed  throughout  GAO’s  analysis  (Table  2). 


TABLE  1.  MAGNITUDE  OF  COST  GROWTH,  BY  SHIP  OR  SUB,  AND 
PRIME  CONTRACTOR 


DDG-91 

DDG-92 

CVN-76 

CVN-77 

LPD-17 

LPD-18 

SSN-774 

SSN-775 

%  of  Cost 

Growth 

10% 

20% 

14% 

13% 

139% 

95% 

27% 

37% 

$  of  Cost 

$35M 

$71M 

$424M 

$434M 

$896M 

$373M 

$273M 

$404M 

Growth 

Prime 

Ingalls 

Bath 

New- 

New- 

Avon- 

Avon- 

Electric 

New- 

Contractor 

Iron 

port 

port 

dale 

dale 

Boat 

port 

Works 

News 

News 

News 

Source:  GAO-05-183  (February  2005) 


Identified  as  a  lower  cost-growth  program,  the  Arleigh  Burke  class  was 
built  by  Ingalls  and  Bath  Iron  Works  (BIW),  while  the  Navy  retained  design 
control.  Ingalls  reported  growth  in  labor  costs,  linked  to  inexperienced 
workers  and  design  upgrades.  When  assimilated  into  Northrop  Grumman, 
Ingalls  realized  some  economies  on  material  costs,  but  overhead  costs 
rose  due  to  pension  plans,  medical  benefits,  and  workload  delays  driven  by 
new  programs.  BIW’s  labor  costs  were  also  driven  up  by  design  upgrades; 
its  overhead  costs  increased  due  to  medical-benefits  costs  and  workload 
delays.  Also  noted  as  a  lower  cost-growth  program,  the  Nimitz  class  was 
produced  by  Newport  News  Shipbuilding.  Labor  costs  rose  due  to  talent 
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TABLE  2:  SHIPBUILDER  COST  CATEGORIES  AS  PERCENTAGE  OF 
OVERALL  COST  GROWTH 


DDG-91 

DDG-92 

CVN-76 

CVN-77 

LPD-17 

LPD-18 

SSN-774 

SSN-775 

Labor 

Direct  Labor 

Indirect  Labor  Costs 

105 

66 

35 

42 

33 

48 

55 

42 

Materials 

Steel,  copper,  titanium 
Tooling  &  misc.  parts 

Subcontractors 

-49 

23 

46 

31 

47 

24 

49 

49 

Overhead 

Insurance 

Pensions 

Holiday  pay 

Facilities  &  utilities 

Taxes 

44 

11 

19 

26 

20 

28 

-3 

9 

Navy-Furnished 

Equipment 

Weapons 

Electronics 

Propulsion  equip. 

not  cited 

not  cited 

not  cited 

not  cited 

Total 

100 

100 

100 

99 

100 

100 

101 

100 

Source:  GAO-05-183  (February  2005) 


shortages,  overtime,  design  changes,  and  late  material  deliveries.  Material 
cost  increases  were  tied  to  specialty  materials  and  subcontracting. 
Overhead  costs  grew  due  to  accounting  changes,  medical-care  costs, 
capital  investments,  pension  plans,  and  workload  changes. 

The  highest  cost-growth  program  was  the  San  Antonio  class  of  ships, 
built  by  Northrop  Grumman.  Labor  costs  increased  due  to  design  difficulties, 
schedule  delays,  and  labor  shortages.  Material  costs  were  increased  by 
subcontractor  efforts  and  tool  development  costs.  Overhead  costs  were 
driven  up  by  pension  plans,  workload  losses,  and  schedule  changes. 

For  the  Virginia  class,  on  which  Electric  Boat  was  Design  Agent,  the 
drivers  of  cost  growth  were  similar  to  those  on  Navy-led  programs:  design 
issues,  schedule  volatility,  material  cost  increases,  overhead-rate  changes, 
and  workload  fluctuations.  These  sources  of  cost  growth  are  obviously  not 
unique  to  LSI-type  arrangements. 
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RAND  (2006),  which  also  assessed  cost  escalation  for  naval  ships, 
corroborated  GAO  on  root  causes.  RAND  attributed  cost  growth  to 
economy-driven  factors  (pension  plans,  labor  rates)  and  customer- 
driven  factors  (design  changes,  schedule  changes).  Both  RAND  and  GAO 
highlight  the  notion  that  cost  growth  is  exacerbated  by  lack  of  “perfect 
information”  (from  traditional  economic  theory),  particularly  at  program 
inception  (Downs,  1964). 


METHODOLOGY  2:  QUALITATIVE  ANALYSIS  INTEGRATED  WITH  NETWORK 
THEORY 

Many  analysts  believe  that  expertise  comes  from  the  private  sector,  but 
power  resides  in  the  public  sector.  This  logic  is  sound  from  a  pure,  follow- 
the-money  perspective:  Public  organizations  exert  power  by  funding 
private  companies  to  carry  out  their  missions.  However,  when  private  firms 
act  as  government  agents,  spearheading  efforts  involving  a  diverse  cast 
of  players,  this  view  is  oversimplified.  The  author  drew  from  network  and 
complexity  theory  (Goldsmith  &  Eggers,  2004;  Agranoff,  2007)  to  explore 
relationships  among  entities  in  LSI-like  arrangements. 

Within  the  social  sciences,  complexity  theory  presents  organizations 
as  learning  organisms  that  launch  agents  on  non-linear  feedback  loops, 
acting  interdependently  with  little  intervention  from  controlling  entities. 
Such  networks  of  agents  engage  in  cooperative  behavior,  eventually 
flattening  hierarchies.  These  ideas  counter  the  command-and-control 
mentality  so  integral  to  DoD  culture.  Still,  this  positive  self-direction  is 
motivated  by  feedback  from  other  actors,  as  well  as  the  environment. 
The  more  involved  agents  become  in  challenging  work,  the  stronger 
connections  become,  making  the  (decidedly  non-linear)  process  easier 
the  next  time. 

While  the  network  construct  highlights  the  enduring  nature  of  human 
intelligence  and  ambition,  it  fails  to  address  some  interactions  among 
private  and  public  organizations.  Underlying  all  business  arrangements 
are  profit  motivations,  information  asymmetry,  and  power.  Synthesizing 
the  literature,  the  following  arguments  can  be  made  for  Design  Agent,  LSI, 
and  TSPR  relationships: 

•  Brainpower.  Private-sector  talent  can  compensate  for 
shortfalls  in  the  DoD  workforce. 

•  Streamlining  and  agility.  Contractors  can  organize  more 
efficiently  to  coordinate  complex  programs.  Less  bound  by 
rules  and  traditions,  they  can  adroitly  assemble  the  required 
mix  of  talent. 

On  the  other  hand,  contracting  out  vital  functions  has  downsides,  such 
as  clashes  over  data  rights  and  friction  among  LSI  subcontractors  and 
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customers.  While  some  information  exchanges  move  fluidly  through  the 
LSI  hierarchy,  each  company  is  subject  to  financial  and  legal  barriers  that 
cannot  be  crossed. 

1.  Erosion  of  government  expertise.  Long-term  programmatic 
knowledge  may  be  sacrificed  when  contractors  provide  technical 
leadership. 

2.  Checks  and  balances.  Communications  protocol  and  decision¬ 
making  processes  are  seldom  adequately  articulated  in  contractual 
terms  and  enacted  via  daily  interaction  (e.g.,  if  the  government 
has  statutory  rights  to  do  independent  testing,  how  does  this 
mesh  with  the  contractor’s  test  plans?). 

3.  Interpretation  problems.  Prime  contract  requirements  are  not 
always  conveyed  accurately  to  subcontractors;  this  becomes 
progressively  more  difficult  at  each  lower  level  on  the  supply 
chain. 

4.  Culture  change.  Ongoing  education  on  roles  and  responsibilities 
in  non-traditional  arrangements  is  needed,  and  can  obstruct  open 
dialogue. 

5.  National  team  concept.  With  geographically  dispersed  industry 
teams,  causes  of  technical  problems  are  sometimes  hard  to 
pinpoint.  Internal  strife  associated  with  jockeying  for  future  scope 
and  funding  is  another  risk. 

6.  Increased  scrutiny.  In  Congressional  budgets,  LSI-like 
arrangements  appear  as  a  single  program  element,  rather  than 
dozens  of  smaller  ones.  More  scrutiny,  albeit  with  less  detailed 
understanding,  is  applied  at  the  top  level. 

7.  Organizational  conflicts  of  interest.  As  members  of  an  LSI  team 
with  common  program  objectives,  individuals  must  share  a  great 
deal  of  information.  Today’s  collaborators  may  be  competing 
against  one  another  for  follow-on  work,  so  firewalls  are  often 
erected  within  and  among  entities. 

8.  Profit  pressures.  Minor  problems  are  sometimes  downplayed  until 
design  and  development  efforts  are  complete  (Baron,  2007).  Over 
time,  minor  issues  can  lead  to  protracted  delays,  cost  overruns, 
and  program  failure  (Ratnam,  2001). 

9.  Concentration  of  power.  The  limited  pool  of  LSI-capable 
companies  may  negatively  impact  innovation,  diversity  of 
subcontractors,  and  fair  business  practices. 

Both  theory  and  experience  suggest  that  mid-1990s  Acquisition 
Reform  initiatives  have  compromised  DoD's  ability  to  coordinate  and 
control  its  programs.  The  outsourcing  of  key  management  and  technical 
functions  may  lead  to  a  long-term  loss  of  institutional  knowledge. 
Moreover,  outsourcing  without  strong  oversight  seems  to  have  diminished 
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the  degree  of  meaningful  cost  and  performance  data  from  the  actual 
performers  (i.e.,  subcontractors  and  suppliers  to  the  LSI),  negatively 
impacting  DoD’s  leverage  in  negotiating  and  executing  its  acquisition 
programs.  Of  course,  all  nine  of  the  preceding  delineated  disadvantages 
can  be  overcome  by  strengthening  the  government  program  office. 
Conversely,  the  espoused  advantages  of  contractor-led  efforts  can  also  be 
maximized  by  a  smarter,  more  efficient,  less  rule-bound  DoD  organization, 
particularly  in  the  interrelated  areas  of  program,  business,  and  human 
resources  management. 


PROGRAM  MANAGEMENT 

In  contracting  relationships,  DoD  expects  commitment  and 
competence  from  private  firms.  However,  DoD  must  possess  enough 
capability  internally  to  ascertain  whether  those  expectations  are  being  met. 
As  Goodsell  states,  “in-house  mission  control”  is  needed  to:  (1)  interact 
responsibly  with  contractors,  and  (2)  exercise  due  diligence.  Crawford  and 
Krahn  (1998)  corroborate  the  need  for  a  solid,  balanced  relationship:  Key 
ingredients  are:  (1)  a  competent  government  customer,  and  (2)  consistent 
oversight.  This  requires  not  just  the  technical  proficiency  to  formulate  a 
vision  (Prencipe,  Davies,  &  Hobday,  2003),  but  also  the  energy  to  enforce 
the  terms  of  the  contract.  In  other  words,  the  government  must  not  only 
have  high  standards;  it  must  also  remain  steadfast  in  holding  contractors 
to  those  standards. 

Certainly  standards  and  steadfastness  are  both  hard  to  maintain, 
but  mustering  the  strength  to  hold  contractors  accountable  is  the  more 
difficult.  In  light  of  the  author’s  experience  in  both  hemispheres  of  the  DoD 
acquisition  world,  this  rings  especially  true.  DoD  employees  are  generally 
entrusted  with  greater  responsibilities;  yet  they  are  confronted  with  more 
obstacles,  such  as  cumbersome  procurement  processes,  antiquated 
office  equipment,  inadequate  staffing,  ineffective  personnel  systems,  and 
more  compressed  pay  scales  than  those  found  in  industry.  Rainey  and 
Steinbauer  (1999)  echo  that:  Public  organizations  are  noted  for  lethargy 
precipitated  by  red  tape.  Much  can  be  overcome,  though,  if  key  employees 
are  committed  to  making  a  positive  difference. 


HUMAN  RESOURCES  MANAGEMENT 

Success  is  often  stymied  by  efforts  to  balance  effective  operations 
with  control  using  democratic  processes.  Government  managers  can  be 
discouraged  by  constraints,  engaging  less  than  vigorously  in  motivating 
subordinates  and  support  contractors,  in  optimizing  workflow  and 
communication,  and  in  carrying  out  their  missions.  Reasons  for  this  are 
myriad:  inexperience,  relatively  short  terms  in  their  positions,  complicated 
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laws  and  regulations,  diffusion  of  responsibility,  and  limited  incentives 
(Rainey,  2003). 

Crawford  and  Krahn  suggest  that  government  does  poorly  with 
acquiring,  retaining,  organizing,  and  channeling  technical  competence. 
To  attract  and  retain  technical  talent,  Asch  (2005,  pp.  309-342) 
advocates  pay-for-performance  systems  with  a  base-plus-incentive-pay 
plan,  and  individual  plus  group  incentives.  Public-sector  longevity  can 
also  be  encouraged  via  pay  structures  that  differentiate  more  with  each 
successive  pay  band:  Simply  put,  extra  responsibility  should  carry  more 
compensation. 


BUSINESS  MANAGEMENT 

The  right  incentives,  coupled  with  human  energy,  sacrifice,  teamwork, 
accountability,  and  a  healthy  work  environment,  lead  to  program  success 
(Baron,  2007).  These  factors  emanate,  at  least  partially,  from  competitive 
zeal.  People  want  to  be  successful,  and  will  try  to  attain  their  goals  rationally 
(Downs,  1964).  Extending  notions  of  rationality  and  utility  maximization 
from  the  individual  to  the  collective,  organizations  must  compete  for 
work  within  their  competencies,  and  identify  others  for  work  that  does 
not  fit.  For  example,  Gholz  (2004)  suggests  that  smaller  organizations, 
with  lower  overhead  costs  and  financial  pressures,  are  well  positioned  to 
conduct  analyses  and  small-scale  experiments  (Ratnam,  2001).  Likewise, 
free  of  future  production  and  profit  interests,  Federally  Funded  Research 
and  Development  Centers  (FFRDCs)  and  DoD  laboratories  could  capably 
serve  as  LSIs. 

Contracting,  whether  with  FFRDCs,  small  businesses,  or  large 
corporations,  is  integral  to  the  way  DoD  carries  out  its  mission.  As  such, 
efforts  should  be  made  to  recruit  and  retain  professionals  capable  of: 
(a)  setting  goals  and  developing  strategy;  (b)  inspiring  those  doing  the 
work  with  commitment,  enthusiasm,  and  a  sense  of  public  purpose;  (c) 
monitoring  technical  work  and  financial  data;  (d)  managing  interfaces 
between  contractor  and  end-users,  as  well  as  the  external  environment;  (e) 
identifying  and  mitigating  risk;  (f)  instituting  a  rigorous  award  fee  process; 
(g)  finding  ways  to  back-load  contractual  incentives,  so  that  performance 
will  be  rewarded  at  the  end  of  the  effort;  and  (h)  conducting  meaningful 
analysis  to  support  negotiations. 


Conclusions 

Clearly,  change  is  imminent.  The  Weapon  Systems  Acquisition  Reform 
Act  of  2009,  coupled  with  recent  legislation  on  LSI-type  contracts, 
was  stimulated  by  rhetoric  on  runaway  costs,  schedule  disruptions,  and 
contractor  performance  issues,  as  well  as  the  ever-present  scarcity  of 
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resources.  A  full-scale  rebalancing  of  risks  and  rewards  is  needed  for 
DoD  to  improve  the  way  it  does  business.  Proposals  include  stronger 
government  roles  throughout  development,  more  time  between  the 
development  and  production  phases,  fewer  design  changes,  and 
standardization  of  engineering  plans.  These  ideas  call  for  wholehearted 
investment  in  program,  business,  and  human  resources  management- 
all  key  competencies,  regardless  of  the  acquisition  strategies  currently 
in  vogue.  DoD  must  attract,  develop,  reward,  and  retain  motivated, 
experienced,  reflective  practitioners. 
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ACHIEVING  OUTCOMES 
BASED  LIFE  CYCLE 
MANAGEMENT 

i  Lou  Kratz  and  Bradd  A.  Buckingham 

Over  the  course  of  60  years,  DoD  has  attempted  to  improve 
its  acquisition  and  life  cycle  process  through  a  series  of  incre¬ 
mental  changes  to  address  requirements  creep,  cost  growth, 
funding  instability,  and  technical  risk.  Unfortunately,  these 
innovations  have  not  improved  cost,  schedule,  or  technical 
performance  of  DoD  programs.  Currently,  the  United  States 
faces  significant  economic  and  national  security  threats 
from  near-peer  competitors,  rogue  states,  and  transnational 
terrorist  organizations.  This  multiplicity  of  threats  requires 
an  agile,  cost-efficient  process  to  mature  and  sustain  mili¬ 
tary  capabilities.  This  article  explores  fundamental  changes 
needed  within  government  and  industry  to  evolve  a  highly 
agile  and  responsive  life  cycle  process. 


Keywords:  Acquisition,  Logistics,  Effects-Based 
Requirements,  Industry-Government  Partnerships, 
Commercial 
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Background 

The  Department  of  Defense  (DoD)  acquisition  and  sustainment 
processes  are  straining  underthedemandsoftheGlobal  War  on  Terror  and 
an  emerging  shortage  of  skilled  acquisition  and  sustainment  professionals. 
Significant  cost  and  schedule  growth,  extended  development  cycles, 
schedule  delays,  elongated  logistics  response  times,  and  increasing 
backorders  are  evidence  of  those  strains.  The  Government  Accountability 
Office  (GAO)  documented  a  36  percent  cost  growth  for  major  defense 
acquisition  programs  and  characterized  DoD  logistics  as  high  risk 
(Government  Accountability  Office  [GAO],  2008).  Additionally,  the  DoD 
continues  to  struggle  to  keep  pace  with  and  develop  new  technologies, 
and  is  no  longer  the  catalyst  driving  the  development  of  new  revolutionary 
technology  (Hagar,  2008). 

In  July  2008,  the  Defense  Science  Board  (DSB)  issued  its  report, 
“Creating  an  Effective  National  Security  industrial  Base  for  the  21st 
Century:  An  Action  Plan  to  Address  the  Coming  Crisis.”  The  report  provided 
specific  recommendations  to  enable  the  DoD  to  achieve  lower  costs,  field 
capabilities  faster,  and  improve  logistics  support.  The  DoD  also  issued 
revised  guidance  on  implementing  a  life  cycle  management  framework 
that  focuses  on  life  cycle  metrics,  aligning  resources  and  readiness,  and 
implementing  performance-based  life  cycle  product  support  (Young, 
2008).  In  March  2009,  the  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS) 
issued  CJCS  Instruction  3170. 01G.  The  intent  of  the  revised  guidance  on 
the  Joint  Capabilities  Integration  and  Development  System  was  to  improve 
the  requirements  process  (CJCS,  2009). 

The  Weapon  Systems  Acquisition  Reform  Act  of  2009  is  the  most 
recent  attempt  to  reform  the  DoD  acquisition  and  life  cycle  process.  The 
act  includes  provisions  to  enhance  oversight,  foster  independent  cost 
estimates,  and  improve  the  DoD  acquisition  workforce.  These  provisions 
are  directed  toward  addressing  DoD’s  challenges  with  requirements, 
stability,  cost  growth,  and  schedule  delays. 

Our  current  national  security  posture  and  budget  realities  dictate 
that  DoD  and  industry  continue  to  explore  and  refine  new  acquisition  and 
sustainment  processes  to  enable  greater  agility  and  capability  at  reduced 
costs.  To  appreciate  the  challenges  DoD  faces  in  achieving  that  agility, 
one  must  first  review  the  path  that  DoD  and  industry  have  traveled  since 
World  War  II. 


THE  WORLD  WAR  II  ACQUISITION  AND  LOGISTICS  ENVIRONMENT 

The  acquisition  process  during  World  War  II  focused  on  mass 
production  of  weapon  and  support  systems,  as  the  American  economy 
served  as  the  heart  of  the  Allied  war  effort.  The  United  States  produced 
over  2.4  million  vehicles,  88,000  tanks,  and  303,000  aircraft  during 
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the  war,  with  the  lend-lease  program  exporting  $57.4  billion  worth  of 
equipment  to  its  Allies.  U.S.  production  exceeded  that  of  the  Allies  and 
adversaries  combined  (Dana,  1998).  The  ability  of  the  U.S.  industrial  base 
to  rapidly  transition  from  civilian  to  defense  production  enabled  the  Allied 
victory  in  World  War  II  (Dana,  1998). 


ACQUISITION  AND  LOGISTICS  DURING  THE  COLD  WAR 

In  1945,  U.S.  industrial  capacity  transitioned  from  a  wartime  footing  to 
a  commercial  market  burgeoning  with  pent-up  demand.  Commonality  in 
manufacturing  processes,  similarity  in  products,  and  a  dramatic  increase 
in  demand  for  consumer  durables  made  for  a  relatively  smooth  transition 
to  a  peacetime,  consumer-driven  economy. 

The  subsequent  emergence  of  the  Soviet  Union  as  a  peer  competitor 
gave  birth  to  a  dedicated  defense  industry  that  focused  on  developing  and 
manufacturing  the  increasingly  complex  systems  needed  for  deterrence 
(Defense  Science  Board,  2007).  Weapon  systems  acquisition  during  this 
period  displayed  several  market  characteristics: 

•  A  monolithic  threat  enabled  the  United  States  to 
concentrate  on  relatively  stable  and  predictable 
requirements. 

•  A  national  decision  to  capitalize  on  technology  to  seize  and 
maintain  qualitative  superiority  led  DoD  and  industry  to 
concentrate  on  equipment  performance. 

•  A  robust  set  of  industrial  competitors  enabled  DoD  to 
experiment,  develop,  and  prototype  needed  technologies 
while  capitalizing  on  competitive  market  forces. 

•  A  national  decision  to  forward-deploy  forces  in  Europe  and 
Korea  encouraged  large  logistics  footprints  of  supplies, 
personnel,  and  maintenance  facilities  to  also  be  forward- 
deployed. 

•  A  national  will  supported  DoD  efforts  and  provided  funding 
at  approximately  5-15  percent  of  the  GDP  (Center  for 
Strategic  and  Budgetary  Assessments,  2006). 

•  A  supportive  environment  of  exploratory  technology 
tolerated  test  failures  and  allowed  new  data  findings. 

The  DoD  and  industry  became  increasingly  governed  by  unique 
government  practices— first  in  engineering  and  manufacturing,  then 
in  finance  and  business— with  the  DoD  specifications  and  standards 
numbering  30,000  by  1980  (Poston,  2003).  These  specifications  and 
standards  drove  a  wedge  between  defense  and  commercial  industries 
and  served  as  significant  barriers  for  non-defense  firms  trying  to  enter  the 
defense  market. 
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The  continuing  DoD  challenges  with  requirements  stability,  technical/ 
risk  management,  funding  stability,  and  the  lack  of  schedule  adherence 
produced  a  national  will  that  after  three  decades  of  Cold  War,  began  to 
demand  more  efficiency  and  accountability  within  defense  acquisition 
and  logistics. 


THE  REAGAN  ERA 

Beginning  in  the  early  1980s,  a  series  of  incremental  policy  directives 
attempted  to  address  skyrocketing  weapons  costs  and  increasing 
development  schedules.  In  April  1981,  Deputy  Secretary  of  Defense  Frank 
Carlucci  presented  32  initiatives  for  reducing  weapon  systems  costs, 
shortening  development  time,  and  improving  weapons  readiness  and 
support  (Carlucci,  1981).  One  goal  of  the  initiatives  was  to  control  cost 
growth  by  attempting  to  achieve  realism  in  cost  estimating. 

Secretary  Carlucci  also  introduced  the  concept  of  Preplanned  Product 
Improvement  (P3I)— a  means  to  deploy  systems  and  sequentially  upgrade 
them  over  time  (Carlucci,  1981).  This  strategy  was  intended  to  minimize 
technological  risk,  and  quicken  the  pace  of  modernization  of  the  nation’s 
armed  forces.  Other  recommendations  included  the  production  of  weapon 
systems  at  more  efficient  rates,  reduction  in  the  number  of  DoD  directives, 
more  advantageous  use  of  competition,  and  greater  use  of  standardized 
subsystems  and  support  equipment.  These  initiatives  represented  a 
comprehensive  list  of  measures  with  the  potential  to  lower  costs,  but  did 
not  address  the  major  causes  of  cost  growth  in  weapon  systems  such  as 
technical  risk,  requirements  creep,  and  cost-plus  business  arrangements 
(Foelber,  1982). 

During  this  period,  Congress  also  took  steps  to  curb  the  rising  cost  of 
weapon  systems,  including  the  introduction  of  more  rigorous  DoD  reporting 
requirements,  the  establishment  of  audit  procedures  for  acquisition 
activities,  and  wider  use  of  multi-year  contracts  (Lockwood,  1983). 


THE  PACKARD  COMMISSION 

President  Reagan  established  the  Packard  Commission  in  1986  to 
reduce  the  inefficiencies  in  the  defense  procurement  system,  with  an 
emphasis  on  the  acquisition  process.  The  Commission’s  conclusions 
supported  the  results  of  numerous  prior  studies,  reporting  that  the 
acquisition  process  suffered  from  schedule  delays,  cost  overruns,  and 
inefficient  performance  (The  President’s  Blue  Ribbon  Commission  on 
Defense  Managment,  1986).  The  Commission  recommended  streamlining 
the  acquisition  process,  increasing  the  amount  of  tests  and  prototypes, 
and  improving  planning. 

A  subsequent  review  of  269  completed  defense  contracts  found 
that  the  Packard  Commission’s  recommendations  were  ineffective  in 
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reducing  cost  overruns.  Despite  implementing  over  two  dozen  initiatives, 
no  considerable  progress  in  defense  program  cost  performance  was 
realized  for  over  30  years  (Christensen,  Searle,  &  Vickery,  1999).  The 
recommendations  did  little  to  fundamentally  change  the  DoD  acquisition 
system  that  favored  expensive,  long  programs,  as  shown  in  Table  1. 

TABLE  1.  THE  EFFECT  OF  PACKARD  COMMISSION 
RECOMMENDATIONS  ON  DEFENSE  COST  PERFORMANCE 


Contract  Phase  Managing  Services 


All  Development  Production  Air  Navy  Army 

Contracts  Contracts  Contracts  Force 


Number  of 

Contracts  (n) 

269 

8 

188 

113 

134 

22 

Final  overrun 

before  imple¬ 
mentation  (%) 

5.6 

4.1 

6.2 

2.8 

7.6 

8.1 

Final  overrun 

after  imple¬ 
mentation  (%) 

9.5 

15.3 

7.2 

12.7 

6.1 

17.0 

Difference  (%) 

3.9 

11.2 

1.0 

9.9 

-1.5 

8.9 

Statistical 

significance 

(P) 

0.055 

0.014 

0.294 

0.003 

0.206 

0.110 

(Christensen,  Searle,  &  Vickery,  1999) 


HISTORIC  FUNDING 

Figure  1  presents  defense  outlays  as  a  percent  of  gross  domestic 
product.  As  shown,  defense  spending  has  continuously  declined  from 
1950  through  the  present.  The  recent  spike,  associated  with  the  Global 
War  on  Terror,  is  projected  to  decline  in  the  outyears,  placing  increased 
pressure  on  DoD  modernization  accounts. 


THE  END  OF  THE  COLD  WAR 

By  the  end  of  the  Cold  War  an  industrial  structure,  an  acquisition 
process,  and  a  logistics  system  existed  that  was  mismatched  with  the 
priorities  of  the  American  people  and  the  global  security  environment. 
The  DoD  had  honed  an  acquisition  process  that  focused  on  providing 
technologically  superior  systems  with  industry  geared  up  to  produce 
those  systems  in  large  quantities.  With  the  dissolution  of  the  Soviet  Union, 
the  American  public  shifted  its  priorities  to  domestic  issues.  Multiple 


Percent 
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FIGURE  1.  DEFENSE  OUTLAYS  AS  A  SHARE  OF  GROSS  DOMESTIC 
PRODUCT 
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administrations,  through  the  1990s,  responded  to  this  shift  in  focus 
through  force  reductions,  base  closures,  and  industrial  consolidation 
(GlobalSecurity.org,  2003). 


SPECIFICATIONS  AND  STANDARDS  REFORM 

In  1994,  Secretary  of  Defense  William  Perry  issued  DoD  policy  to 
increase  access  to  state-of-the-art  technology  and  adopt  the  same 
business  practices  as  world-class  commercial  suppliers.  The  directive 
attempted  to  reduce  the  complexity  and  costs  that  DoD  incurred  when 
purchasing  major  weapon  systems  and  their  numerous  maintenance 
requirements. 

Secretary  Perry  chartered  a  detailed  cost  analysis  allowing  the  DoD 
to  determine  the  most  important  cost  drivers  in  the  quest  for  standards 
reform.  The  study  concluded  that,  on  average,  the  DoD  paid  a  regulatory 
cost  premium  of  approximately  18  percent.  The  study  also  indicated 
that  significant  cost  savings  were  achievable  through  reductions  in 
DoD  regulation  and  oversight  (Coopers  &  Lybrand/TASC  Project  Team, 
1994).  Since  Secretary  Perry  introduced  his  plan  to  reform  the  acquisition 
process,  over  1,200  commercial  standards  have  been  adopted  by  the  DoD; 
however,  DoD  has  not  fully  capitalized  on  commercially  available  solutions 
(Office  of  the  Secretary  of  Defense,  1994). 
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FIGURE  2.  THE  DoD  "DEATH  SPIRAL" 
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The  procurement  accounts  declined  in  the  late  1990s,  with  fewer  new 
systems  under  development  and  existing  weapons  platforms  continuing 
to  age  and  remain  in  service  well  past  their  intended  life  cycles.  This 
extended  use  resulted  in  increasing  operations  and  maintenance  (O&M) 
costs,  which  contributed  to  a  life  cycle  “Death  Spiral”  of  further  deferred 
modernization,  as  shown  in  Figure  2  (Gansler,  1998). 

To  attack  this  “death  spiral,”  Secretary  Gansler  launched  an  aggressive 
acquisition  and  logistics  reform  effort  (Gansler,  1999).  Key  initiatives 
included  increased  use  of  commercial  items,  evolutionary  acquisition, 
streamlined  acquisition  documentation,  and  performance  based  logistics. 
These  initiatives  emphasized  greater  civil-military  integration  and  were 
directed  towards  increasing  acquisition  and  logistics  agility. 


JOINT  CAPABILITIES  INTEGRATION  AND  DEVELOPMENT  SYSTEM  (JCIDS) 

The  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 
was  created  in  2003  to  address  shortfalls  in  the  DoD  requirements 
generation  system.  Identified  by  the  U.S.  Joint  Chiefs  of  Staff,  these 
shortfalls  included  not  considering  new  programs  in  the  context  of  other 
programs,  not  sufficiently  considering  combined  service  requirements,  not 
effectively  prioritizing  joint  service  requirements,  and  not  accomplishing 
sufficient  analysis. 

The  JCIDS  process  codifies  a  DoD  policy  shift  away  from  threat-based 
assessments  to  capabilities-based  assessments  of  warfighter  needs.  As 
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FIGURE  3.  THREAT  VS.  CAPABILITY-BASED  PLANNING 


Requirements  Generation  Joint  Capabilities  Integration 

System  (RGS)  -  -30  years  of  and  Development  System 
experience  (JCIDS)  -  2  years  old 


a  replacement  for  developing,  producing,  and  fielding  systems  based  on 
perceived  threats  to  the  nation,  JCIDS  policy  enables  the  development 
of  capabilities  based  on  strategic  direction  and  priorities  defined  in  the 
National  Military  Strategy  and  National  Defense  Strategy,  as  shown  in 
Figure  3  (Chadwick,  2007). 


THE  GLOBAL  WAR  ON  TERROR 

Despite  the  perceived  "peace  dividend,”  the  migration  from  a  bi-polar 
world  to  a  multipolar  world  proved  more  challenging  than  anticipated. 
The  DoD  continued  to  rely  on  acquisition  processes,  organizations,  and 
infrastructure  largely  developed  in  the  years  following  World  War  II. 
Technical  superiority  had  proven  successful  against  a  peer  competitor; 
however,  rapid  advancement  in  commercially  available  computing  and 
telecommunications  empowered  multiple  new  threats;  e.g.,  transnational 
terrorism  and  rogue  state  actors.  This  multiplicity  of  threats  demanded 
greater  agility  and  innovation  at  the  same  time  DoD  acquisition  and  its 
associated  industrial  base  were  contracting.  The  Global  War  on  Terror 
(GWOT)  has  provided  the  United  States  lessons  directly  related  to  DoD 
acquisition  and  sustainment.  These  lessons  include: 


Our  requirements  process  is  slow  to  react  to  a  rapidly 
adaptive  adversary. 
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•  Our  acquisition  process  consumes  billions  of  dollars  against 
threats  generated  at  a  fraction  of  that  cost. 

•  Our  mass  logistics  structure  is  insufficient  to  support  rapid, 
dispersed  forces. 

In  September  2008,  Secretary  of  Defense  Robert  Gates  spoke  at  the 
National  Defense  University  and  addressed  these  issues: 

The  need  for  the  state-of-the-art  systems— particularly  longer 
range  capabilities— will  never  go  away,  as  we  strive  to  offset 
the  countermeasures  being  developed  by  other  nations.  But 
at  a  certain  point,  given  the  types  of  situations  we  are  likely  to 
face— and  given,  for  example,  the  struggles  to  field  up-armored 
HUMVEES  [High  Mobility  Multipurpose  Wheeled  Vehicles], 
MRAPs  [Mine  Resistant  Ambush  Protected  (vehicles)],  and  ISR 
[intelligence,  surveillance,  and  reconnaissance]  in  Iraq— it  begs  the 
question  whether  specialized,  often  relatively  low-tech  equipment 
for  stability  and  counterinsurgency  missions  is  also  needed. 

Secretary  Gates  continued: 

Why  did  we  have  to  go  outside  the  normal  bureaucratic  process  to 
develop  counter-IED  [improvised  explosive  device]  technologies, 
to  build  MRAPs,  and  to  quickly  expand  our  ISR  capability?  In  short, 
why  did  we  have  to  bypass  existing  institutions  and  procedures  to 
get  the  capabilities  we  need  to  protect  our  troops  and  pursue  the 
wars  we  are  in?  Our  conventional  modernization  programs  seek 
a  99  percent  solution  in  years.  Stability  and  counterinsurgency 
missions— the  wars  we  are  in— require  75  percent  solutions  in 
months.  The  challenge  is  whether  in  our  bureaucracy  and  in  our 
minds  these  two  different  paradigms  can  be  made  to  coexist. 


TIME  FOR  CHANGE 

The  answer  to  Secretary  Gates’  question  can  be  found  in  the  historic 
evolution  of  our  nation’s  DoD  life  cycle  process.  Since  the  end  of  World 
War  II,  the  DoD  developed  and  refined  an  acquisition  process  focused  on 
responding  to  a  predictable,  monolithic  threat.  This  process  built  upon 
several  underlying  principles,  including  a  desire  for  U.S.  technological 
superiority,  a  competitive  industrial  base,  and  a  relatively  long  planning 
and  requirements  horizon. 

Over  the  course  of  60  years,  DoD  attempted  to  improve  its  acquisition 
and  life  cycle  process  through  a  series  of  incremental  changes  to  address 
requirements  creep,  cost  growth,  funding  instability,  and  technical  risk. 
Despite  numerous  studies  and  reforms,  these  incremental  efforts  did 
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TABLE  2.  GEOPOLITICAL  DIFFERENCES 


1945-1990 

Today 

Threat:  Bipolar  threat.  Enabled  the 
United  States  on  relatively  stable 
and  predictable  requirements 
(Soviet  Union) 

Threat:  Multipolar  threat. 
Transnational  terrorism,  near-peer 
competitors,  and  rogue  state 

actors 

Technology:  A  national  decision 
to  capitalize  on  technology  to 
seize  and  maintain  qualitative 
superiority  led  DoD  and  industry 
to  concentrate  on  equipment 
performance.  Military  technology 
as  the  driving  force 

Technology:  DoD  no  longer  the 
catalyst  driving  the  development 
of  new  revolutionary  technology. 
Commercial  technology  the 
driving  force 

Requirements:  Concentrated  on 
relatively  stable  and  predictable 
requirements.  Match  or  counter 
Soviet  weapons  systems 

Requirements:  Unpredictable  and 
unstable  with  the  multiplicity  of 

threats  and  behavior.  Adversaries 

with  current  events  driving 
requirements 

Acquisition  &  Sustainment: 

A  robust  set  of  conventional 

industrial  competitors  enabled 

DoD  to  experiment,  develop,  and 
prototype  needed  technologies 
while  capitalizing  on  competitive 
market  forces.  Incremental  change 

Acquisition  &  Sustainment: 

Systems  and  cost  demands  of  the 
Global  War  on  Terror,  increasing 
Congressional  oversight,  and  a 
shortage  of  skilled  acquisition 
and  sustainment  professionals. 
Significant  cost  and  scheduled 
growth  of  major  defense 
programs,  extended  development 
cycles,  schedule  slips,  elongated 
logistics  response  times,  and 
increasing  backorders 

National  Will:  A  national  will 

that  supported  DoD  efforts  and 
provided  funding  at  approximately 
5—15%  of  the  Gross  Domestic 

Product 

National  Will:  National  will 

skeptical  and  increasingly 
unwilling  to  accept  continued 
rampant  defense  spending 

not  improve  cost/schedule  control  nor  provide  the  inherent  agility  that 
is  required. 

The  geopolitical  environment  that  underlies  DoD’s  acquisition  and 
logistics  processes  has  fundamentally  changed  over  the  past  60  years,  as 
summarized  in  Table  2.  These  dramatic  changes  dictate  that  DoD  develop 
an  acquisition  and  life  cycle  process  that  is  efficient  and  agile  to  respond 


Achieving  Outcomes-Based  Life  Cycle  Management 


January  2010 


to  current  threats.  Such  changes  cannot  be  achieved  via  incrementalism 
because  the  fundamental— the  underlying  principles— have  changed. 

Over  the  last  two  decades,  the  nature  of  conflict  has  fundamentally 
changed,  and  much  of  America's  defense  establishment  has  yet  to  adjust 
to  the  security  realities  of  the  post-Cold  War  world  and  the  complex  and 
dangerous  new  century.  The  acquisition  and  logistics  environment  of  the 
21st  century  needs  a  course  of  action  that  will  decisively  enable  greater 
agility  and  efficiency.  Such  agility  might  be  achievable  by  returning  to 
our  historic  reliance  on  a  competitive,  integrated  industrial  base  (such 
as  we  enjoyed  prior  to  and  during  World  War  II).  That  reliance  could  be 
enhanced  by: 

•  Establishing  a  top-down,  competitive  requirements  process 
that  fosters  competing  alternative  solutions  and  industrial 
innovation 

•  Implementing  a  product  development  process  that  builds 
upon  inherent  industry  incentives  and  product  investment 

•  Defining  a  product  support  logistics  model  that  is  focused 
on  readiness  and  capitalizes  on  best-in-class  practices  in 
government  and  industry. 

The  potential  effects  of  these  changes  are  contrasted  to  incremental 
efforts  in  Table  3. 


Becoming  Highly  Agile  and  Responsive 


EFFECTS-BASED  REQUIREMENTS 

"Requirements  creep”  has  been  a  persistent  problem  within  defense 
acquisition  since  World  War  II.  This  “creep”  is  driven  by  the  DoD  focus  on 
technological  superiority  and  the  military  services  historic  bias  towards 
unique  requirements.  The  JCIDS  process  (and  subsequent  portfolio 
management)  was  intended  to  correct  these  problems;  however,  the 
Joint  Staff  was  never  fully  resourced  to  develop  capstone  and  integrating 
concepts.  As  a  result,  the  JCIDS  process  continues  to  be  dominated  by 
Service-driven  requirements.  The  most  recent  Chairman  Joint  Chiefs  of 
Staff  Instruction  (CJCSI)  3170. OIG  re-emphasizes  those  relationships 
by  establishing  the  sponsoring  agent  (Services)  as  responsible  for 
creating  requirements  documents,  while  the  Joint  Staff  and  Combatant 
Commanders  (COCOMs)  are  responsible  for  review  and  coordination. 

For  DoD  to  enhance  agility,  it  must  begin  with  a  top-down  requirements 
process  that  is  appropriately  focused  on  the  military  effort  that  is 
required.  Requirements  would  be  characterized  based  upon  desired  effect 
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TABLE  3.  SUMMARY  TIMELINE  FOR  ACQUISITION  AND  LOGISTICS 
CHARACTERISTICS  AND  OUTCOMES 


Acquisition  and  Logistics 

Acquisition  and  Logistics 

Characteristics 

Outcomes 

Reform 

Attempt 

Strengths 

Weaknesses 

Capability 

Agility 

Efficiency 

Packard 

Attention  to 

Expensive, 

Yes 

No 

No 

Commission 

acquisition 

lengthy 

streamlining 

acquisitions 

continue 

Specifications/ 

Best 

Modernization 

Yes 

No 

No 

Standards 

commercial 

“death  spiral” 

Reform 

practices 

Joint 

Capabilities 

Disconnect 

Yes 

No 

No 

Capabilities 

based  on  joint 

between  born 

Integration  and 

warfighter 

joint  and 

Development 

System 

(JCIDS) 

needs 

employed  joint 

The  Weapon 

•  Independent 

No  inherent 

Yes 

No 

No 

Systems 

cost 

performance 

Acquisition 

estimates 
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or  outcome,  rather  than  as  a  specific  system.  The  proposed  top-down 
process  would  include  the  following: 

•  Functional  Capabilities  Boards  would  prepare  the  Initial 
Capabilities  Document  (ICD)  based  upon  input  from  the 
COCOMs.  By  their  nature,  these  ICDs  would  focus  on 
military  need  and  effect. 

•  The  ICD  would  be  approved  by  the  Joint  Capabilities 
Board  (JCB)  and  the  Joint  Requirements  Oversight  Council 
(JROC). 

•  The  ICD  would  then  be  provided  to  all  DoD  sponsoring 
agents  to  assess/consider  alternative  solutions  to  the 
ICD.  These  efforts  would  include  competitive  industrial 
participation  during  Material  Solutions  Analysis  (MSA). 

•  The  potential  sponsoring  agents  would  present  the 
results  of  their  efforts  and  a  draft  capability  development 
document  (CDD)  to  the  JCB  and  JROC  to  select  a  preferred 
solution. 

•  Once  approved,  the  CDD  would  form  the  basis  for  a  Material 
Solutions  Board  (MSB)  decision  to  proceed  with  a  program. 

This  proposed  process  would  strengthen  the  Joint  Staff  and  COCOM 
role  in  requirements  development  and  would  require  additional  analytic 
resources  within  the  Joint  Staff.  The  process  also  would  foster  competitive 
evaluation  of  alternative  solutions  and  enhance  innovation. 

Effects-based  requirements  would  make  maximum  use  of  Joint 
Staff  resources  for  integrated  “Concepts  of  Operation,”  while  fostering 
innovation  within  the  Services  and  industry  to  develop  competing 
solutions.  Industry  would  be  empowered  to  provide  a  specific  capability 
rapidly,  within  the  constraints  of  the  Concept  of  Operations. 


COMMERCIALLY  DRIVEN  RESEARCH  AND  DEVELOPMENT 

The  DoD  acquisition  process  reinforces  unique  solutions  via  built-in¬ 
bias  for  large,  long,  cost-plus  development  programs.  These  programs 
inherently  embody  incentives  for  cost  and  schedule  growth  and  limited 
incentives  for  efficiency.  DoD  and  the  Congress  have  attempted  to 
regulate  efficiency  for  20  years  via  increased  oversight  and  reporting,  but 
the  overall  process  is  impervious  to  incremental  change. 

Currently,  the  defense  industry  develops  a  customized  product  with 
capabilities  specified  in  advance  for  the  individual  Services.  The  DoD  bears 
the  up-front  investment  in  development  costs.  This  process  incentivizes 
industry  to  pursue  a  technological  track  driven  by  projected  performance, 
with  limited  incentives  to  enhance  technology  maturation  or  reduce  risk. 
This  is  in  stark  contrast  to  the  commercial  product  development  process, 
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where  industry  invests  in  development  costs  with  an  equal  emphasis  on 
maturation  and  innovation  (Dombrowski  &  Gholz,  2006). 

The  “new  normal”  of  persistent  conflict  and  stabilization  engagement 
demands  a  new  normal  research  and  development  business  model. 
Advances  in  technology  research  and  development  (R&D)  are  currently 
led  by  the  commercial  world,  where  R&D  has  increased  steadily  at  a  rate  of 
about  5  percent  per  year  for  more  than  20  years.  During  this  same  20-year 
period,  DoD  and  government  R&D  spending  dropped  2.5  percent  per  year 
(DoD,  2000).  For  DoD  to  capitalize  on  commercial  investment,  it  must 
actively  engage  the  commercial  market. 

The  new  R&D  business  model  would  be  more  akin  to  the  commercial 
development  process,  where  industry  manages  product  R&D  (and  is 
fully  responsible  for  technology  maturation  of  that  product).  DoD  would 
continue  to  invest  in  basic  research  within  the  6.1  and  6.2  accounts,  and  in 
test  and  evaluation  of  competing  prototypes.  This  would  incentivize  the 
defense  industry  to  control  requirements  creep,  select  mature  technologies 
for  product  integration,  and  develop  solutions  in  an  incremental,  timely 
fashion.  The  model  naturally  incentivizes  industry,  as  defense  companies 
would  be  funding  product  development  versus  the  cost-plus  development 
of  today.  The  result  is  a  solid,  business-driven  mechanism  that  both 
moderates  technical  risk  and  ensures  technical  maturity  (Gholz,  2007). 

A  consequence  of  increased  control  of  R&D  investment  by  the  defense 
industry  is  that  there  will  be  times  when  the  warfighter  customer  will  not 
be  interested  in  the  technological  improvements  the  defense  industry  has 
developed  and  offers  for  sale.  To  offset  this,  the  defense  industry  and  the 
warfighter  will  have  to  develop  a  strategic  planning  process  that  recognizes 
warfighter  requirements  and  identifies  desirable  product  improvements 
before  developing  a  particular  platform  (Gholz,  2007). 

Additionally,  defense-related  companies  would  increase  their 
technological  and  market  risk  as  they  assume  more  responsibility  for 
investment  decisions,  as  they  will  be  required  to  put  their  own  money  on 
the  line  to  advance  their  technological  core  competencies.  Similar  to  the 
commercial  industry,  defense-related  companies  would  offer  the  products 
they  have  developed,  with  the  development  cost  already  included  in  the 
price—  prior  to  offering  them  for  sale  to  warfighters.  The  warfighters  would 
then  bear  little  technological  risk,  due  to  basic  product  performance 
characteristics  already  having  been  developed  and  well  understood  at  the 
time  of  the  sale  (Gholz,  2007).  Such  a  model  would  include  the  following 
key  attributes: 

•  DoD-funded  basic  research  and  technology  maturation 
through  6.1,  6.2,  and  6.3a 

•  Industry  engagement  in  competitive  concept  development 
via  the  revised  requirements  process 
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•  Industry-funded  product  development  following  an  MSA/B 
decision 

•  Government-funded  test  and  evaluation,  which,  if 
successful,  enables  a  full  production  decision. 

This  model  may  not  be  appropriate  for  multifaceted,  high-risk  weapons 
platforms,  such  as  aircraft  carriers  or  nuclear  submarines.  However,  it  should 
be  appropriate  for  the  system  of  systems  that  comprise  these  platforms, 
information  technologies,  and  the  growing  number  of  items  required  for 
“persistent  presence.”  This  approach  will  require  fundamental  change 
within  DoD  to  accept  industry-matured  technologies  and  equipment  built 
to  commercial  standards. 


OUTCOME-BASED  PARTNERSHIP  LIFE  CYCLE  PRODUCT  SUPPORT 

In  the  2001  Quadrennial  Defense  Review,  the  DoD  mandated  the 
implementation  of  Performance  Based  Logistics  (PBL)  with  the  goal  to 
gain  the  most  efficient  and  effective  performance  of  weapon  systems 
throughout  their  life  cycles,  and  to  build  successful  business  partnerships 
that  align  with  the  goals  of  all  involved  parties  for  the  duration  of  these 
programs  (Berkowitz,  2005).  PBL  is  a  business  partnership  model 
designed  to  align  the  interests  of  both  the  DoD  and  the  logistics  service 
provider,  creating  value  and  the  desired  outcomes  of  both  partners.  This 
yields  a  more  cooperative  venture  than  merely  achieving  Service-level 
agreements  or  getting  the  lowest  price  from  the  provider. 

PBLs  are  employed  across  a  broad  range  of  systems,  such  as  aviation 
tires,  subsystems  such  as  engines,  and  complete  weapon  systems  (e.g.,  F-22). 
More  than  200  PBL  efforts  are  ongoing  DoD-wide  that  have  demonstrated 
material  availability  above  95  percent  and  commercial  response  times  of 
2-4  days  (versus  a  DoD  average  of  16  days)  (Estevez,  2006). 

The  dramatic  change  in  the  U.S.  security  posture  from  1997  to  2001 
provided  significant  real-world  observations  associated  with  DoD’s  PBL 
efforts.  These  include: 

•  When  appropriately  incentivized,  industry-government 
partnerships  can  provide  improved  material  availability 
at  reduced  costs  while  mitigating  obsolescence,  reducing 
inventory,  and  reducing  demand. 

•  Performance  based  arrangements  are  complex  and  require 
a  knowledgeable  DoD  life  cycle  workforce  that  has  core 
competencies  in  all  product  support  functions  and  full 
insight/oversight  of  contract  and  agreement  execution. 
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•  Performance  based  arrangements  are  successful  at  the 
component,  subsystem,  and  system  level,  depending  upon 
the  unique  circumstance  of  the  system. 

•  Government  should  procure  access  and  rights  to  system 
technical  data  to  enable  long-term  sustainment  and 
competition. 

•  DoD  employs  forces  in  a  joint  and  coalition  environment; 
thus,  sustainment  strategies  must  reflect  enterprise  as  well 
as  weapon  systems  requirements. 

•  Depot  partnering  integrated  industry  and  government 
resources;  however,  partnering  across  other  aspects  of 
product  support  is  difficult. 

•  Long-term  contracts  limit  government  flexibility  to  adjust  to 
real-world  changes;  therefore,  sustainment  strategies  must 
be  agile  and  sufficiently  flexible  to  enable  DoD  to  adjust  to 
operational  demands  and  budget  realities. 

•  Performance  based  arrangements  are  incentivized  for  the 
contractor  to  engineer  reliability  improvements  into  the 
system.  The  benefits  are  twofold:  fewer  repairs  for  the 
contractor  and  less  remove-and-replace  actions  for  the 
flight  line  maintainer. 

These  key  observations  form  the  basis  for  a  revised  product  support 
business  model  that  is  responsive  to  today’s  threat  environment,  builds 
upon  the  best  from  government  and  industry,  and  reinforces  transparency 
and  accountability.  Key  objectives  of  such  a  model  include: 


•  Outcome  and  performance-based  across  the  life  cycle,  with 
full  cost  and  performance  transparency 

•  Contractual  relationships  that  inherently  include  flexibility 
to  adjust  to  real-world  operational  and  budget  dynamics 

•  Government-industry  partnerships  that  span  all  product 
support  elements  and  foster  shared  responsibility  for 
integrated  outcomes 

•  Improved  portfolio  and  enterprise  integration  led  by 
government  capabilities 

•  Clear  government  accountability  with  associated  insight/ 
oversight  of  industrial  providers 

•  Appropriate  balance  of  government  and  industry  providers  that 
enables  development  and  retention  of  government  capability. 


Achieving  Outcomes-Based  Life  Cycle  Management 


January  2010 


Combining  these  emerging  aspects  with  previously  demonstrated 
successes  and  observations  yields  a  product  support  model  that  is 
effective,  efficient,  and  flexible.  Key  elements  of  the  model  include: 

•  The  program  manager  is  the  life  cycle  product  support 
manager  and  the  single  point  of  accountability  for  readiness 
and  cost. 

•  PBL  successes  of  the  past  decade  are  improved  upon, 
with  a  broader  tool  box  of  partnering  solutions  and  flexible 
contract  strategies. 

•  DoD  owns  rights  and  has  access  to  all  technical  data 
necessary  to  support  the  system  through  its  entire  life  cycle. 

•  DoD  retains  responsibility  for  configuration  management 
following  final  design  review.  Industry  provides 
configuration  management  services  and  status  accounting. 

•  Product  support  service  providers  are  re-assessed  on  a 
5-year  basis  following  the  rate  production  decision. 

•  Government-industry  partnerships  are  established  for  all 
product  support  elements  early  in  the  life  cycle. 

•  Initial  integrated  logistics  support  analyses  explicitly 
consider  enterprise  assets. 

•  Weapon  systems  product  support  information  is  integrated 
into  overall  enterprise  information  systems. 

•  Closed-loop  health  monitoring  and  prognostic  capabilities 
are  established  to  enable  effective  fleet  management. 

•  Integrated  logistics  support  and  level  of  repair  analysis  are 
continuously  re-evaluated  based  upon  field  experience 
provided  by  the  closed-loop  system. 

The  proposed  model  is  a  hybrid  of  current  promising  practices  and, 
therefore,  is  dependent  upon  several  key  enablers,  including: 

•  Establishing  a  comprehensive  capability  for  the  program 
manager  to  function  as  the  life  cycle  manager,  consistent 
with  PM  accountability  and  responsibility  (although  this 
is  designated  in  policy  today,  the  program  management 
curriculum  includes  very  little  formal  training  in  sustainment) 

•  Developing  a  robust  government  workforce  of  life  cycle 
product  support  professionals  who  support  the  program 
manager 

•  Implementing  transparent  cost  accounting  systems  within 
the  government  that  inherently  enable  capturing  and 
reporting  costs  on  a  weapon  systems  basis 
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•  Creating  appropriate  management  and  oversight  structures 
that  enable  organic  providers  to  commit  to  programmatic 
and  system-level  outcomes 

•  Creating  contractual  mechanisms  that  enable  government- 
industry  partnerships  while  ensuring  effective  government 
oversight 

•  Defining  appropriate  and  necessary  information  system 
interfaces  that  enable  enterprise-wide  transparency  and 
visibility 

•  Enabling  more  transparent  product  support  to  the 
warfighter  and  more  warfighter  advocacy  for  affordable, 
readiness-based  product  support  objectives. 

These  enablers  address  significant  structural  issues  that  will  require 
statutory,  policy,  and  business  process  changes.  These  changes  may  span 
over  a  decade. 


Conclusions 

Despite  fond  memories  of  past  glories,  cost  and  schedule  control 
has  been  a  persistent  problem  within  defense  acquisition  since  World 
War  II.  The  DoD  acquisition  and  life  cycle  processes  have  proven  to  be 
impervious  to  incremental  improvements,  despite  decades  of  study  and 
recommendations.  It  is  certain  that  for  the  foreseeable  future  we  as  a 
nation  will  face  a  severely  constrained  fiscal  environment  that  will  put 
added  downward  pressure  on  defense  and  other  discretionary  budget 
elements.  This  uncertainty  requires  an  acquisition  process  that  is  agile  and 
efficient ,  enabling  the  DoD  to  rapidly  field  and  sustain  capabilities. 

This  situation  necessitates  an  enterprise-wide  Defense  Department 
application  of  the  proven  life  cycle  management  practices  that  will  ensure 
greater  performance  improvements  and  simultaneous  cost  savings.  These 
significant  savings  opportunities  in  turn  can  be  deployed  to  address  the 
significant  force  modernization  and  recapitalization  requirements  that  we 
face  today  and  in  the  future. 
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PRE-MILESTONE  A  COST 
ANALYSIS:  PROGRESS, 
CHALLENGES,  AND 
CHANGE 

f  Martha  "Marti”  A.  Roper 

The  natural  law  of  inertia:  matter  will  remain  at  rest  or  continue 
in  uniform  motion  in  the  same  straight  line  unless  acted  upon 
by  some  external  force. 

Clement  W.  Stone 

After  three  years  of  parallel  research  and  application  efforts 
aimed  at  enabling  pre-Milestone  A  cost  analysis,  the  time 
investment  has  produced  dividends  of  progress  and  lessons 
learned  for  a  team  of  Army  researchers.  Clearly,  early  acqui¬ 
sition  investment  decisions  must  be  cost-informed,  and  the 
demand  for  this  early  cost  information  is  growing.  Although 
concrete  tools  are  being  developed  to  enable  the  analysis 
to  support  early  investment  decisions,  it  will  not  be  achiev¬ 
able  without  an  analysis  culture  with  the  policy,  procedure, 
and  willingness  to  develop  and/or  accept  cost  estimates 
that  are  less  precise  than  those  developed  at  Milestone  B  or 
Milestone  C.  Making  early  analysis  a  reality  will  require  large- 
scale,  department-wide  culture  change  within  and  around 
the  analysis  community. 


Keywords:  Pre-Milestone  A,  Cost  Analysis, 
Acquisition  Process,  Joint  Capabilities  Integration 
and  Development  System  (JCIDS),  Analysis  of 
Alternatives,  Capability-Based  Cost  Analysis,  DoDI 
5000.02,  Concept  Decision 
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Although  Pre-Milestone  A  cost  analysis  is  a  relatively  unfamiliar 
concept  in  defense  analysis,  its  application  is  increasingly  being 
researched  and  leveraged  by  a  team  of  Army  analysts  at  the  Office  of 
the  Deputy  Assistant  Secretary  of  the  Army  for  Cost  and  Economics 
(ODASA-CE).  Simply  stated,  a  cost  analysis  aims  to  inform  the  decision¬ 
making  process  with  specific  types  of  information,  namely  measures 
in  monetary  terms  of  willingness  to  pay  for  a  change  by  those  who  will 
benefit  from  it,  and  the  willingness  to  accept  the  change  by  those  who 
will  lose  from  it.  After  three  years  of  parallel  research  and  application 
efforts,  the  team’s  time  investment  has  produced  dividends  of  progress 
and  lessons  learned.  Clearly,  early  acquisition  investment  decisions  must 
be  cost-informed;  and  now  more  than  ever,  the  demand  for  this  early  cost 
analysis  information  is  growing. 

But  how  can  cost  estimates  be  developed  so  early  with  so  little  system 
definition?  Three  major  elements  enable  pre-Milestone  A  cost  estimating. 
The  first  is  an  analysis  framework  that  can  make  use  of  qualitative  capability 
data  (along  with  any  physical,  technical,  and  performance  data  available 
at  that  time)  to  produce  a  cost  estimate.  The  second  is  a  cumulative  high- 
level  cost  data  source  that  links  systems  to  their  capability  sets.  The  third 
is  an  analysis  culture  with  the  policy,  procedure,  and  willingness  to  develop 
and/or  accept  cost  estimates  that  are  less  precise  than  those  developed  at 
Milestone  B  or  Milestone  C. 

The  first  element,  the  capability-based  analysis  framework,  has 
been  developed  and  is  being  continuously  refined  and  applied  under 
the  ODASA-CE  internal  research  efforts  (Roper,  2007a).  The  second 
element,  the  high-level  capability  mapping  coupled  to  cost  data,  has  been 
developed,  populated,  and  is  growing  as  more  data  become  available 
(Roper,  2007b).  The  third  element,  however,  is  one  that  involves  more  than 
mere  research  and  data  collection.  It  requires  large-scale,  department¬ 
wide  culture  change  within  and  around  the  analysis  community.  Clearly, 
without  this  third  element,  an  ample  supply  of  elements  one  and  two  alone 
will  not  enable  capability-based,  early  cost  estimating. 


Observations  and  Lessons  Learned 

As  a  result  of  the  2004  Quadrennial  Defense  Review  (QDR)  emphasis 
on  earlier  investment  decision  making  within  the  department,  OUSD(AT&L) 
initiated  the  Concept  Decision  Experiment  (2006-2008).  This  trial  process 
took  four  pilot  capability  sets  through  a  Concept  Decision  investment 
decision,  where  the  key  innovation  was  that  the  three  key  department 
stakeholders  (or  Tri-Chair)— acquisition,  resourcing,  and  requirements— 
participated  in  the  decision  forum  and  committed  (from  their  respective 
lanes)  to  whichever  alternative(s)  was  selected. 
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An  analysis  process  leading  up  to  this  event— the  Evaluation  of 
Alternatives  (EoA)— supported  the  Concept  Decision.  It  was  similar  to 
what  is  known  as  an  Analysis  of  Alternatives  (AoA)  within  DoD,  except 
that  it  was  broader,  less  granular,  and  included  non-materiel  solutions 
analysis.  The  evaluation  and  selection  of  an  alternative  was  to  be  cost-  and 
risk-informed,  and  coupled  with  some  measure  of  how  well  the  alternative 
filled  the  capability  gap. 

One  of  the  main  objectives  of  the  Concept  Decision  Experiment  was 
to  enable  early  concept  decisions  that  evaluate  a  trade  space  of  materiel 
and  non-materiel  alternatives  to  fill  capability  gaps.  A  desired  outcome  of 
this  early  investment  decision  making  is  more  stable  defense  acquisition 
programs.  Although  the  Tri-Chair  Concept  Decision/EoA  model  was  not 
adopted,  some  sweeping  acquisition  reform  measures  resulted  from  the 
experiment.  Up  until  that  point,  most  materiel  solutions  in  the  acquisition 
cycle  were  not  required  to  be  reviewed  until  Milestone  B,  effectively 
tailoring  out  the  acquisition  entry  point  and  Milestone  A. 

In  the  aftermath  of  the  Concept  Decision  Experiment,  the  Concept 
Decision  point  was  recast  as  the  Materiel  Development  Decision  (MDD), 
a  mandatory  entry  point  to  the  acquisition  process.  At  the  MDD,  the 
Milestone  Decision  Authority  (MDA)  determines  to  which  milestone  the 
solution/capability  set  proceeds.  A  clear  and  already  evident  result  of  this 
change  is  that  many  more  Milestone  A  analyses  are  deemed  necessary 
for  solutions  proceeding  through  the  acquisition  process.  The  AoA 
requirements  remain  relatively  unchanged  (from  an  analysis  character 
point  of  view);  however,  due  to  the  increased  incidence  of  early-analysis 
Milestone  A’s,  the  use  of  AoAs  has  become  much  more  prevalent.  These 
changes  were  all  formally  instituted  through  the  Department  of  Defense 
Instruction  (DoDI)  5000.02  revision  in  December  2008. 


PRECISION  CONSIDERATIONS  AT  MILESTONE  A 

Intuitively,  the  primary  focus  of  the  ongoing  Army  research  is  how 
to  enable  early  cost  analysis  (and  its  context).  One  of  the  terms  used  to 
describe  the  cost  analysis  required  for  an  AoA  at  Milestone  A  is  rough 
order  of  magnitude  or  ROM  (DoD,  2006).  However,  the  term  ROM  is 
problematic  in  that  it  has  a  well-understood  mathematical  definition  that 
does  not  apply  to  the  common  DoD  use  of  the  term.  A  more  accurate 
way  to  characterize  cost  analysis  at  or  before  Milestone  A  is  to  observe 
that  the  estimate  range  (indicating  the  range  of  probable  costs)  would  be 
wider  due  to  reduced  system  definition  and  greater  uncertainty,  as  shown 
in  the  Figure.  To  date,  no  comprehensive  effort  is  ongoing  to  characterize 
the  form  and  expectation  of  pre-Milestone  A  analysis;  therefore,  great 
diversity  in  interpretation  prevails  across  the  department. 
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FIGURE.  IMPACT  OF  SYSTEM  MATURITY  ON  COST  ESTIMATE 
RANGES 
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Probabilistically  speaking,  any  one  point  estimate  has  a  zero  percent 
chance  of  being  correct.  As  any  cost  analyst  will  confirm,  risk  analysis  is  an 
important  element  of  any  cost  analysis  result.  On  its  own— and  important 
to  note— is  that  a  pre-Milestone  A  point  estimate  is  not  very  informative 
on  its  own— it  must  include  a  risk  analysis  or  a  cost  range  to  capture  the 
uncertainty  associated  with  the  estimate.  As  we  add  precision  by  adding 
system  definition  and/or  analysis  resources,  our  certainty  around  the 
associated  point  estimate  will  narrow.  Intuition  indicates  that  the  range 
around  the  point  cost  estimate  will  narrow  as  we  move  from  Milestone  A 
to  Milestone  B  to  Milestone  C  (see  Figure). 

One  analyst  might  believe  a  pre-Milestone  A  estimate  is  a  range 
estimate  based  on  one  or  more  variables  that  gives  a  reasonable  level  of 
confidence.  Another  might  believe  it  to  be  very  similar  to  a  Milestone  B  cost 
estimate  (filling  the  many  data  gaps  with  assumptions),  with  the  ability  to 
perform  detailed  variable  what-if  drills.  Clearly,  an  unambiguous  definition 
is  needed  of  what  a  pre-Milestone  A  estimate  is  and  what  level  of  analysis 
is  considered  acceptable.  At  or  before  Milestone  A,  if  the  system  concept 
is  at  the  level  of  maturity  expected  at  that  time  (likely  not  well-defined), 
it  would  seem  that  the  analysis  should  be  something  appreciably  less 
detailed  than  at  Milestone  B.  In  fact,  the  level  of  system  definition  required 
to  build  a  detailed  cost  estimate  may  not  exist,  or  may  require  extensive 
creative  assumption-making  that  may  not  be  appropriate.  Moreover,  if  the 
intent  is  to  provide  a  way  to  distinguish  between  alternatives  to  inform 
prudent  investment  decisions,  then  a  less  precise  estimate,  coupled  with 
risk  ranges  and  measures,  may  be  exactly  what  is  required. 


ENABLING  DEPARTMENT-WIDE,  CAPABILITIES- BASED  COST  ANALYSIS 

Pre-Milestone  A  decision  making  often  occurs  in  a  data-poor 
environment.  Prior  to  Milestone  A,  requirements  or  desired  capabilities  are 
known,  but  additional  information  is  limited.  Often,  only  general  solution- 
type  information  is  available.  For  cost  analysis  techniques  to  be  relevant 
prior  to  Milestone  A,  they  must  take  into  account  all  available  information. 
One  method  of  dealing  with  this  data-poor  environment  is  to  engage  in 
capability-based  cost  analysis. 
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Capability-based  cost  analysis  begins  with  the  idea  that  system 
capabilities  are  related  to  system  cost.  Once  a  link  between  capabilities 
and  cost  is  established  for  existent  systems,  this  mapping  can  be  used 
to  estimate  the  cost  of  future  systems  based  on  their  capabilities.  If 
additional  information  is  known  or  becomes  available,  it  can  be  used  to 
improve  the  estimate’s  accuracy.  Capability  data  join  physical,  technical, 
and  performance  data  as  relevant  data  sources  and  bases  for  analysts’ 
estimates. 

Capability-based  cost  analysis  and  pre-Milestone  A  cost  analysis  are 
two  distinct  concepts.  While  the  necessity  of  cost  analysis  during  pre- 
Milestone  A  often  requires  the  inclusion  of  capability-based  cost  analysis 
techniques,  capability-based  analysis  has  utility  after  Milestone  A  has 
come  and  gone.  Capability-based  cost  analysis  is  relevant  at  all  stages 
of  a  system’s  life  cycle;  it  can  aid  in  identification  of  analogous  systems 
and  methodology  development  whenever  applicable  and  appropriate.  To 
date,  the  focus  of  capability-based  analysis  has  been  to  provide  system 
acquisition  costs.  However,  capability-based  cost  estimating  can  also  derive 
costs  for  maintenance  or  disposal.  Two  main  advantages  of  capability- 
based  cost  analysis  are  that  it  can  be  done  with  limited  data  and  that  it 
provides  a  relatively  intuitive  output.  At  times,  when  minimal  information 
is  available,  capability-based  analysis  enables  the  rapid  development  of 
estimates  that  can  be  reassessed  and  refined  once  additional  information 
is  known.  Since  capability-based  cost  analysis  is  based  on  fairly  simple 
concepts,  it  produces  an  intuitive  end  product  that  is  attractive  to  decision 
makers  (Hull,  2009). 

One  of  the  keys  to  the  effective  use  of  capability-based  cost  analysis  is 
that  it  requires  the  generation  of  variables  specific  enough  to  meaningfully 
differentiate  among  systems  and  capability  sets,  but  broad  enough  to  be 
used  with  the  limited  information  available  at  Milestone  A.  One  of  the  first 
tasks  undertaken  by  the  team  was  to  devote  significant  research  and  data 
collection  time  to  searching  for  a  standardized,  broad  set  of  capabilities. 
This  capability  set  had  to  be  unambiguous  in  language,  extremely  precise 
in  description,  and  valid  for  use  as  a  classifier  or  variable.  Although  the 
immediate  intuition  led  us  to  the  Joint  Capability  Areas  (JCA)  or  Joint 
Integrated  Activity  Sets  (JIAS),  our  efforts  to  conform  these  architectures 
to  our  particular  requirements  yielded  little. 

However,  the  System  Capabilities  Architecture  (SCA),  the  capability 
variable  set  developed  and  used  by  ODASA-CE,  leverages  much  from  the 
JCA,  and  in  fact  maps  directly  to  it  with  our  capability-based  cost  analysis 
tool— the  Capabilities  Knowledge  Base  (CKB)  (Sibert,  2009).  In  addition, 
the  SCA  is  a  fluid  entity  that  continues  to  evolve  based  on  improvement 
of  available  information  and  subject  matter  expert/peer  review.  As  new 
systems  are  added  to  the  CKB  and  knowledge  of  the  acquired  capability 
inventory  grows,  the  SCA  has  and  will  continue  to  change. 
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The  SCA  uses  plainly  worded,  high-level  capabilities  like  “Move,” 
“Shoot,”  “Communicate,”  “Sense  Environment,”  and  “Sustain”  (for 
example),  and  then  drills  down  into  them.  It  enables  the  analyst  to  ask 
questions  such  as,  Does  my  pre-Milestone  A  solution  Move ?  and  be  able 
to  identify  an  unambiguous  yes  or  no  answer.  The  initial  framework  has 
developed,  refined,  and  augmented  into  what  we  believe  is  a  suitable 
structure  for  capabilities-based  parametric  data  analysis.  This  architecture 
is  directly  linked  to  the  JCA  so  that  department  capability  gaps  can 
directly  translate  to  capability-based  analysis.  However,  this  is  certainly  a 
living  document  that  changes  as  we  learn  more  about  the  department's 
currently  acquired  and  future  capabilities. 

When  developing  capability  maps  for  systems  residing  within  the  CKB 
or  for  systems  being  analyzed,  it  is  imperative  to  involve  knowledgeable 
platform  subject  matter  experts  to  the  fullest  extent  possible.  Although 
situations  where  analysis  time  is  limited  (and  therefore  collaboration 
time  is  limited)  certainly  arise,  such  situations  are  suboptimal.  Defining 
a  thoroughly  documented  system  boundary  is  also  important— in  other 
words,  clearly  designate  what  is  included  and  excluded  from  a  system 
(or  capability  set).  Detailed  capability  mapping  procedures  have  been 
developed  to  accompany  the  SCA.  These  are  necessary  in  order  to 
standardize  and  expedite  the  mapping  process,  making  it  transparent  and 
repeatable.  Optimally,  a  CKB  system  user  will  easily  be  able  to  trace  how 
a  system  was  mapped  to  its  capability  set,  or  be  able  to  spot  any  errors 
or  anomalies  quickly.  Capability  mapping  is  an  iterative  process  subject  to 
continuous  improvement  efforts  by  its  community  of  interest  (McCormack 
&  Roper,  2009). 


Conclusions 

The  department-wide  efforts  during  recent  years  to  enable  early 
investment  decision  making  have  demonstrated  the  level  of  difficulty 
inherent  in  achieving  such  an  objective.  Clearly,  a  commitment  to  the 
fiscal  responsibility  and  long-term  acquisition  stability  that  pre-Milestone 
A  decision  making  can  provide  will  require  far-reaching  culture  change 
and  a  willingness  to  look  beyond  the  typical  issue  set.  Pre-Milestone  A 
analysis  is  the  foundation  upon  which  investment  decision  making  is 
built;  understandably,  a  knowledge  and  appreciation  for  some  of  the 
most  challenging  obstacles  to  building  this  foundation  is  imperative.  The 
required  level  of  analysis  and  cost  estimate  detail  must  be  clearly  specified 
so  that  ambiguity  is  kept  to  a  minimum.  Additionally,  the  body  of  analysts 
within  the  department  must  reach  a  common  understanding  of  how  to 
define  and  frame  capability  information  in  order  to  enable  capability-based 
analysis  that  is  universally  understood.  Change  is  not  easy,  and  inertia  is 
difficult  to  counter;  but,  for  early  investment  decisions  to  be  successful, 
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the  forces  of  friction  that  prevent  effective  pre-Milestone  A  analysis  must 
be  overcome. 
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THE  DEMISE  OF  THE 
FEDERAL  GOVERNMENT 
SMALL  BUSINESS 
PROGRAM 

i  Philip  G.  Bail  Jr. 

This  article  examines  the  legislation  leading  up  to  the 
Small  Business  Act  of  1953  and  the  resulting  implemen¬ 
tation  of  congressionally  mandated  small  business  goals; 
industry’s  support  of  small  business  initiatives;  govern¬ 
ment  oversight  of  small  business  plans;  and  the  sometimes 
improper  interpretation  of  rules  and  regulations  affecting 
the  Small  Business  Program  (SBP).  The  combination  of 
mandated  goals,  improper  interpretation  of  regulations, 
and  the  resulting  negative  effect  on  large  businesses  may,  as 
supported  by  the  author’s  research,  be  significant  factors  in 
the  program’s  demise.  Also  included  are  suggestions  on  how 
the  federal  SBP  can  become  a  viable  program  that  benefits 
small  businesses  so  they  truly  receive  an  equitable  share  of 
government  dollars  without  infringing  on  supply  chain  initia¬ 
tives  of  large  business  contractors. 


Keywords:  Small  Business  Act  of  1953,  Small  Business 
Goals,  Small  Business  Plans,  Mandated  Goals,  Small 
Business  Program 
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In  the  winter  2007  issue  of  the  Air  Force  Small  Business  newsletter 
Beyond  Goals,  Scott  Denniston,  then  director  of  the  Office  of  Small  and 
Disadvantaged  Business  Utilization,  Department  of  Veterans  Affairs,  was 
asked  to  assess  the  state  of  the  Service-Disabled  Veteran-Owned  Small 
Business  Program.  Denniston  stated  that  government-wide,  the  3  percent 
goal  for  awards  to  Service-Disabled  Veteran-Owned  Small  Businesses  had 
not  been  met.  He  went  on  to  say  that  in  past  years,  contracting  officers 
had  been  encouraged  to  set  aside  procurements  to  8(a)  certified  small 
businesses,  disadvantaged  small  businesses,  and  women-owned  small 
businesses.  He  could  also  have  included  HUBZone  small  businesses  and 
Native  American-owned  businesses.  Denniston  (Cenkci,  2007)  expressed 
the  hope  that  government  contracting  officers  would  focus  on  veteran- 
owned  small  businesses.  It  is  this  myopic  view  of  the  federal  Small  Business 
Program,  in  my  assessment,  that  will  be  its  demise. 

But  how  did  the  government  arrive,  or  at  what  point  in  time  did  a 
government  agency  or  its  representative  assume  the  untenable  position  of 
promoting  one  type  of  small  business  set-aside,  while  another  government 
entity  might  be  simultaneously  promoting  a  different  set-aside?  What 
effect  does  this  flavor-of-the-month  attitude  have  on  large  business 
supply  chains?  Is  this  current  interpretation  of  the  federal  Small  Business 
Program  the  original  intent  of  Congress?  Does  today's  interpretation  result 
in  fair  and  reasonable  prices?  This  article  explores  these  issues  and  makes 
recommendations  to  help  the  federal  Small  Business  Program  survive 
during  these  uncertain  times. 


Background 

Helping  businesses  in  dealing  with  federal  government  contracts 
began  in  1929  when  Herbert  Hoover  created  the  Reconstruction  Finance 
Corporation  (RFC)  following  the  Great  Depression  (Overview  &  History 
of  the  SBA,  n.d.).  The  RFC  was  created  to  loan  money  to  all  businesses, 
large  and  small,  stymied  by  the  depression.  During  World  War  II,  the 
prevailing  view  was  that  many  small  businesses  could  not  compete  with 
large  businesses  in  making  products  and  providing  services  in  support  of 
war  efforts.  As  a  result,  in  1942  Congress  created  the  Smaller  War  Plants 
Corporation  (SWPC)  (Overview  &  History  of  the  SBA,  n.d.).  This  agency 
provided  loans  to  small  businesses  and  encouraged  federal  agencies  and 
large  businesses  to  buy  from  such  businesses.  Congress  also  passed  the 
Small  Business  Mobilization  Act  of  1942.  This  act  acknowledged  that  a 
price  differential  might  be  necessary  to  keep  small  plants  mobilized,  but 
only  for  war  efforts  (Small  Business  Mobilization  Act,  1942). 

At  the  end  of  World  War  II,  SWPC  was  abolished  and  the  RFC  took  over 
its  lending  and  contract  powers.  The  Department  of  Commerce  also  assumed 
some  of  SWPC's  responsibilities.  The  Department  of  Defense  (DoD)  was 
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pulled  into  the  discussion  of  small  business  participation  in  federal  contracts 
by  the  creation  of  the  Armed  Services  Procurement  Act  of  1947.  This  act 
mandated  that  a  fair  proportion  of  total  federal  contracts  should  be  placed 
with  small  business  (Armed  Services  Procurement  Act,  1947).  The  intent  of 
this  act  was  to  continue  in  peacetime  the  policy  that  had  prompted  the 
enactment  of  the  Small  Business  Mobilization  Act  of  1942. 

As  the  Korean  War  began,  Congress  created  another  wartime 
organization  to  handle  small  business  concerns— the  Small  Defense  Plants 
Administration  (SDPA).  Its  functions  were  similar  to  those  of  the  SWPC. 
The  SDPA  certified  small  businesses  to  the  RFC  when  it  determined  a 
business  had  the  capability  to  perform  the  work  of  government  contracts. 
At  this  same  time,  an  Office  of  Small  Business  (OSB)  in  the  Department  of 
Commerce  assumed  some  educational  responsibilities.  Believing  that  a  lack 
of  information  and  expertise  was  the  main  cause  of  small  business  failure, 
the  OSB  produced  brochures  and  conducted  management  counseling  for 
individual  entrepreneurs.  Congress  also  passed  the  Defense  Production 
Act  of  1950.  This  act  again  emphasized  that  the  preservation  of  small 
business  mobilization  capability  was  necessary,  even  if  awards  were  made 
at  a  higher  rather  than  lower  price  (Defense  Production  Act,  1950). 

By  1952,  the  RFC  was  no  longer  considered  necessary,  but  to 
continue  the  important  functions  of  the  earlier  agencies,  President  Dwight 
Eisenhower  proposed  creation  of  a  new  small  business  agency— the  Small 
Business  Administration. 

In  the  Small  Business  Act  of  1953,  Congress  created  the  Small  Business 
Administration  (SBA),  whose  function  was  to  “aid,  counsel,  assist,  and 
protect,  insofar  as  is  possible,  the  interests  of  small  business  concerns.” 
The  charter  also  stipulated  that  the  SBA  would  ensure  small  businesses 
receive  a  “fair  proportion”  of  government  contracts. 

The  act  stipulated  that  the  definition  of  what  constitutes  a  small  business 
should  vary  from  industry  to  industry  to  reflect  industry  differences  (Small 
Business  Act,  1953).  It  charged  the  SBA  with  establishing  small  business 
size  standards  on  an  industry-by-industry  basis.  Another  stipulation  of  the 
act  was  that  to  be  considered  a  small  business  concern,  the  concern  must 
be  independently  owned  and  operated  and  not  dominant  in  its  field  of 
operation. 

Helping  small  businesses  get  a  “fair  proportion”  of  government 
contracts  as  mandated  by  the  World  War  II  SWPC  charter  and  the  Armed 
Services  Procurement  Act  of  1947  did  not  lead  small  businesses  to  the 
government  as  envisioned.  The  Comptroller  General  issued  a  report  in 
1977  verifying  this  conclusion  saying  these  early  attempts  to  bring  small 
business  into  the  federal  business  environment  had  not  been  successful. 
A  House  Small  Business  Committee  reported  that  small  businesses, 
particularly  those  owned  by  the  disadvantaged,  had  not  been  considered 
fairly  as  subcontractors  and  suppliers  to  prime  contractors  performing 
work  for  the  government  (Clark,  Moutray,  &  Saade,  2006). 
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As  a  result,  Public  Law  (Pub.  L.)  95-507,  a  bill  to  amend  the  Small 
Business  Act  and  the  Small  Business  Investment  Act  of  1958,  was  enacted 
in  1978.  This  law  (Amendment  to  Small  Business  Act  and  the  Small  Business 
Investment  Act  of  1958,  1978)  created  several  significant  changes  to  the 
federal  government  Small  Business  Program.  Specifically,  it— 

•  Made  participation  by  large  businesses  in  some  type  of 
Small  Business  Program  mandatory  instead  of  voluntary 

•  Changed  “best  efforts”  to  "Maximum  Practicable 
Opportunities” 

•  Required  a  small  business  plan  for  procurements  over 
$500,000  (now  $550,000) 

•  Eliminated  the  small  business  “minority-owned”  category 

•  Determined  disadvantaged  business  concerns  as  being  both 
socially  and  economically  disadvantaged1 

•  Reserved  solicitations  under  $25,000  for  small  business 
(now  >$3,000  but  not  over  $100,000) 

•  Required  federal  agencies  to  establish  small  business  goals 
and  explain  to  Congress  when  goals  were  not  met 

•  Established  the  Office  of  Small  and  Disadvantaged  Business 
Utilization  (SADBU)  (now  Office  of  Small  Business  Programs 
in  the  Department  of  Defense). 

The  Small  Business  Act  was  significant  because  the  Small  Business 
Program  now  had  teeth,  and  large  business  participation  could  be  evaluated 
more  definitively  if  still  somewhat  subjectively  regarding  outreach  efforts. 
Congress  also  continued  to  refine  the  program  by  establishing  separate 
setaside  requirements  and  goals  for  additional  categories  of  small 
businesses. 

In  Pub.  L.  99-661,  The  Department  of  Defense  5%  Minority  Contracting 
Goal  (1987),  a  5  percent  Small  and  Disadvantaged  Business  goal,  and  SDB 
setasides  were  implemented.2  In  Pub.  L.  100-656,  Business  Opportunities 
Development  Reform  Act  (1988),  the  8(a)  Program  was  established; 
a  liquidated  Damages  Clause  was  added  to  the  Federal  Acquisition 
Regulation  (FAR)  to  help  ensure  that  goals  were  met;  and  20  percent  was 
identified  as  the  federal  agency  small  business  prime  contract  goal. 

In  Pub.  L.  103-355,  the  Federal  Acquisition  Streamlining  Act  (1994)  was 
enacted.  It  added  a  Women-Owned  Small  Business  goal  of  5  percent.  In 
1997,  the  HUBZone  Act,  Pub.  L.  105-135,  was  passed  (Beale  &  Deas,  2008). 
It  provided  preferences  to  small  business  concerns  located  in  HUBZones 
or  areas  of  high  unemployment.  Such  firms  must  be  owned  and  controlled 
by  one  or  more  U.S.  citizens,  and  at  least  35  percent  of  its  employees  must 
reside  in  a  HUBZone. 

That  same  year  the  federal  agency  small  business  goal  was  increased 
from  20  percent  to  23  percent. 
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Finally,  Pub.  L.  106-50,  the  Veterans  Entrepreneurship  and  Small 
Business  Development  Act  (1999),  established  goals  for  awards  to 
Veteran-Owned  Small  Businesses  and  Service-Disabled  Veteran-Owned 
Small  Businesses.  Those  goals  are  now  3  percent  for  both  Veteran-Owned 
and  Disabled  Veteran-Owned  Small  Businesses. 

The  original  purpose  of  programs  designed  to  help  contractors  do 
business  with  the  federal  government  was  to  loan  money  to  all  businesses 
following  the  great  depression  of  the  late  1920s.  By  1999,  it  had  changed 
to  a  program  that  required  federal  contracting  officers  to  reserve  for  small 
businesses  all  solicitations  expected  to  exceed  $3,000  but  not  exceeding 
$100,000— unless  the  contracting  officer  determined  there  was  no 
reasonable  expectation  of  obtaining  offers  from  two  or  more  responsible 
small  business  concerns  that  are  competitive  in  terms  of  market  prices, 
quality,  and  delivery.  The  FAR,  in  subpart  19.102,  Size  Standards  (FAR 
2005a),  also  required  the  contracting  officer  to  set  aside  any  acquisition 
expected  to  exceed  $100,000  for  small  business  participation  only  when 
there  is  a  reasonable  expectation  that  offers  will  be  obtained  from  at  least 
two  responsible  small  businesses  offering  the  products  of  different  small 
businesses  with  award  at  fair  market  prices.  This  apparent  emphasis  on 
award  at  fair  market  prices  contradicts,  to  some  extent,  the  original  intent 
of  the  Small  Business  Mobilization  Act  of  1942  and  the  Defense  Production 
Act  of  1950. 


Discussion 

Small  businesses  suddenly  had  many  avenues  to  pursue  in  competing 
for  government  contracts,  and  large  businesses  could  no  longer  look  to 
small  businesses  solely  for  Bill  of  Materials,  or  BoM  buildup.  They  now 
had  to  divide  their  vendor  base  into  several  more  categories  such  as 
Disadvantaged  Small  Business,  Women-Owned  Small  Business,  PIUBZone 
Small  Business,  and  Veteran  and  Disabled  Veteran-Owned  Small  Business. 
Moreover,  contracting  officers  expected  to  see  goals  and  goal  achievement 
at  the  levels  identified  by  Congress,  such  as  5  percent  to  Women-Owned 
Small  Businesses,  even  if  Make-or-Buy  analyses  for  a  particular  solicitation 
did  not  support  such  goals. 

These  changed  expectations  and  mandates  regarding  the  use  of 
small  businesses  appear  to  be  overreaching  when  compared  to  the  goal 
set  forth  in  Pub.  L.  95-507  of  giving  small  businesses  the  "...maximum 
practical  opportunity...”  to  compete  for  federal  prime  contract  dollars 
and  subcontract  awards.  Flowever,  the  federal  Small  Business  Program, 
if  interpreted  consistently  using  practical  sound  business  judgment,  may 
still  be  workable. 

Regrettably,  interpretation  is  often  not  grounded  in  common  sense 
and  does  not  follow  the  congressionally  mandated  requirements  identified 
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in  the  FAR  at  subpart  6.1,  Competition  Requirements  (FAR,  2005b), 
which  states,  "...with  certain  limited  exceptions. ..Contracting  Officers  shall 
promote  and  provide  for  full  and  open  competition  in  soliciting  offers  and 
awarding  government  contracts.”3  While  it  can  be  argued  that  providing 
“maximum  practicable  opportunities”  to  small  business  trumps  the 
achievement  of  fair  and  reasonable  prices,  it  is  my  view  that  contracting 
officers  should  always  strive  to  efficiently  fulfill  the  requirements  of  the 
warfighter  at  fair  and  reasonable  prices.  This  is  especially  true  today 
when  services-type  contracts  are  increasing  in  use.  Unless  the  contracting 
officer  is  reasonably  sure  that  a  resulting  contract,  if  set  aside  for  small 
business,  will  be  awarded  at  fair  and  reasonable  prices,  the  solicitation 
should  be  issued  as  open  competition,  large  and  small. 

This  was  echoed  by  John  J.  Young,  former  Under  Secretary  of  Defense 
(Acquisition,  Technology,  &  Logistics).  In  testimony  before  the  Senate 
Committee  on  Armed  Services  on  June  3,  2008,  he  commented  on  a 
Government  Accountability  Office  report  on  weapon  program  outcomes 
(GAO,  2008a). 

Fie  identified  four  strategic  thrust  areas  to  make  federal  acquisition 
better.  One  of  these  thrust  areas  is  to  “Responsibly  Spend  Every  Single 
Tax  Dollar.”  Identifying  complex  acquisitions  for  small  business  setasides 
may  not  always  ensure  responsible  spending  of  tax  dollars  because  the 
best  solutions  to  a  problem  may  not  be  captured  within  the  small  business 
community  and  may  prevent  a  business  with  the  best  technical  and  cost 
solution— a  large  business— from  competing. 

In  fiscal  year  2006,  the  DoD  spent  over  $294  billion  to  procure  goods 
and  services,  with  more  than  one-third  of  this  total  to  subcontractors 
(GAO,  2008b).  Many  of  these  subcontracted  dollars  were  awarded  to  small 
businesses,  as  large  businesses  awarded  subcontracts  to  small  businesses 
as  part  of  their  small  business  outreach  efforts;  and  small  businesses 
awarded  subcontracts  to  other  small  businesses  in  order  to  perform  parts 
of  awarded  contracts. 

With  over  $100  billion  of  federal  acquisition  dollars  potentially  going 
to  small  businesses  in  fiscal  year  2006,  a  case  could  be  made  that  the 
policies  implemented  to  give  small  business  a  fair  opportunity  in  the 
government  marketplace  are  finally  paying  off.  These  results,  while  not 
at  the  congressionally  mandated  goals  for  Veteran  and  Disabled  Veteran- 
Owned  Small  Businesses,  are  in  line  with  congressional  mandates  to  provide 
a  maximum  practical  opportunity  for  small  businesses  to  participate  in  the 
federal  market. 

Flowever,  the  pressure  to  achieve  the  minimum  goals  in  all  small 
business  categories  and  achieve  improved  year-over-year  small  business 
statistics  have  a  sometimes  negative  effect  on  large  business  as  the  various 
changes  to  the  Small  Business  Act  and  individual  contracting  agency 
interpretations  of  the  federal  Small  Business  Program  requirements  unfold. 
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What  are  some  of  these  issues?  While  not  all-inclusive,  they  can  be  broken 
down  into  several  categories. 

•  Mandating  specific  goal  achievement 

•  Requiring  goals  based  on  contract  value,  not 
subcontracting  opportunity 

•  Not  recognizing  the  negative  impact  of  small  business  goals 
on  large  business  supply  chain  decisions 

•  Myths 

•  Reorganization  within  the  Defense  Contract  Management 
Agency 

•  Training  shortfalls  of  government  small  business  specialists 
and  large  business  SBLOs  (Small  Business  Liaison  Officers). 


MANDATING  SPECIFIC  GOAL  ACHIEVEMENT 

Some  government  solicitations  now  mandate  the  small  business 
goals  that  must  be  achieved.  The  mandating  of  goals  may  violate  the  FAR 
19.704(a)(2),  Subcontracting  Plan  Requirements  (FAR,  2005c),  which 
only  require  a  prospective  offeror  to  identify  total  dollars  planned  to  be 
subcontracted.  Dollars  planned  to  be  subcontracted  might  differ  greatly 
from  company  to  company  depending  on  in-house  capability.  A  large 
hazardous  waste  disposal  company  might  have  fully  trained  employees, 
capable  of  performing  all  activities  involved  in  the  pickup,  segregation, 
packaging,  and  transportation  of  hazardous  waste;  while  another  company 
might  have  to  subcontract  various  aspects  of  such  services.  The  small 
business  plans  for  these  two  companies  will  be  very  different  because  the 
companies  are  very  different.  It  is  not  fair  to  the  company  with  in-house 
resources  to  be  penalized  because  its  small  business  plan  is  less  “robust” 
than  the  company  with  limited  resources  that  may  have  to  subcontract 
many  aspects  of  the  services  or  cannot  justify  the  agency-dictated  small 
business  goals. 

The  U.S.  Army  Corps  of  Engineers,  New  York  District,  issued 
solicitation  W912DS-07-B-0011  in  May  2007.  This  Invitation  for  Bid  (IFB) 
identified  various  small  business  goals  it  expected  bidders  to  meet.  The 
IFB  stated,  “If  plan  includes  goals  less  than  indicated,  explain  extenuating 
circumstances  why  Corps  of  Engineering  goals  can’t  be  met....’’ 

The  mandated  small  business  goals  in  this  particular  solicitation  ignore 
the  likely  differences  in  potential  bidders,  but  more  importantly,  may 
violate  the  FAR  in  an  IFB  environment.  FAR  14.301(a),  Responsiveness  of 
Bids  (FAR,  2005d),  states,  “...to  be  considered  for  award  a  bid  must  comply 
in  all  material  respects  with  the  IFB.  Such  compliance  enables  bidders  to 
stand  on  equal  footing  while  maintaining  integrity  of  the  sealed  bidding 
system.”  Discussions  are  not  usually  part  of  an  IFB.  The  winning  contractor 
is  determined  by  lowest  price  among  the  responsive,  responsible  bidders. 
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I  Asking  a  bidder  to  explain  why  its  small  business  plan  does  not  meet  the 

pre-determined  goals  of  the  agency  contradicts  the  rules  for  advertised 
bids.  FAR  19.702(a)(2),  Statutory  Requirements  (FAR,  2005e),  says  that  in 
sealed  bidding  acquisitions,  the  bidder  selected  for  award  must  (if  dollar 
parameters  for  a  small  business  plan  are  met  in  the  bid  price)  submit  a 
subcontracting  plan.  No  other  requirements  are  identified,  and  no  specific 
goal  achievements  are  required  other  than  best  effort.  If  this  solicitation 
was  a  request  for  proposal  (RFP),  discussion  of  small  business  plans  would 
be  more  appropriate  as  such  discussions  would  not  broach  contractor 
responsiveness  issues  to  the  extent  they  would  in  an  IFB  environment. 


REQUIRING  GOALS  BASED  ON  CONTRACT  VALUE,  NOT  SUBCONTRACTING 
OPPORTUNITY 

Some  contracting  officers  are  requiring  small  business  goals  based 
on  "contract  value.”  Other  agencies  are  requiring  that  all  statutory  goals 
be  met  before  a  subcontracting  plan  will  be  accepted.  Both  of  these 
approaches  violate  the  Small  Business  Act,  Section  8(d),  Subcontracting 
Program,  which  ties  goals  to  subcontracting  opportunities,  not  to  contract 
value  or  to  statutory  goal  minimums.  Actual  subcontracting  opportunities, 
while  subjective  to  a  degree,  simply  may  not  support  the  meeting  of 
statutory  goals  because  the  skill  sets  required  in  the  various  small  business 
categories  may  not  be  available  or  the  contractor  may  not  require  outside 
vendor/subcontractor  assistance. 


NOT  RECOGNIZING  THE  NEGATIVE  IMPACT  OF  SMALL  BUSINESS  GOALS  ON 
LARGE  BUSINESS  SUPPLY  CHAIN  DECISIONS 

Another  reality  of  business  today  involves  the  efforts  contractors  are 
making  to  decrease  the  number  of  dollars  they  are  spending  on  outsourced 
materials  and  services.  Many  large  businesses  are  improving  their  supplier 
selection  process  by  eliminating  poor  performers  and  consolidating 
purchases.  Every  time  the  vendor  database  is  reduced,  small  businesses 
may  suffer  in  the  process.  Flowever,  the  typical  large  business  materials 
department  is  a  profit  center  for  its  company  and  is  expected  to  meet 
certain  goals  associated  with  buying  more  for  less.  Large  businesses  are 
increasing  global  sourcing  initiatives  and  maximizing  economies  of  scale 
by  buying  more  quantity  from  fewer  suppliers.  These  initiatives  do  not 
usually  improve  the  small  business  vendor  spend  statistics.  Flowever,  it  is 
not  the  role  of  the  federal  government  to  tell  businesses  how  their  supply 
chains  should  operate. 
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MYTHS 

Myths  about  the  Small  Business  Program  also  generate  their  own 
problems.  For  example,  some  argue  that  the  bundling  of  requirements 
into  large  contracts  prevents  small  businesses  from  performing  on  them. 
The  SBA  supports  this  claim  and  criticizes  agencies  that  combine  similar 
requirements  to  maximize  economies  of  scale.  The  SBA  claims  34,221  new 
bundled  contracts  were  awarded  between  1992  and  2001,  transferring 
$840  billion  of  contract  revenue  from  small  businesses,  causing  a  56 
percent  decline  in  the  number  of  small  businesses  contracting  with  the 
government.  Yet,  only  25  bid  protests  were  filed  by  contractors  between 
1992-2004  over  contract  bundling— sharply  contradicting  the  SBA’s 
estimates  of  bundling  frequency  or  negative  impact  to  small  businesses 
(Nerenz,  2007). 

Another  myth  involves  the  idea  that  innovation  is  exclusively  a  small 
business  phenomenon.  Andy  Grove,  Co-Founder  of  INTEL,  stated  in 
Portfolio  Magazine  (Grove,  2007)  that,  "Some  sectors  are  hobbled  with 
intractable,  industry-wide  problems  that  only  a  large  company  can  solve.” 
Fie  cited  Apple  Computer’s  entry  into  the  music  business  and  Wal-Mart’s 
introduction  of  in-store  health  clinics  as  examples  of  solutions  only  possible 
through  large  business  involvement. 


REORGANIZATION  WITHIN  THE  DEFENSE  CONTRACT  MANAGEMENT 
AGENCY 

The  Defense  Contract  Management  Agency  (DCMA)  reorganized 
itself  to  align  its  limited  resources  to  the  more  specific  types  of  products 
or  services  it  manages  instead  of  the  geographic  orientation  by  physical 
location  to  the  large  businesses  it  monitors.  This  reorganization  has 
resulted  in  limited  face-to-face  contact  between  DCMA  small  business 
specialists  and  the  large  business  SBLOs.  Elimination  of  the  geographic 
proximity  between  DCMA  and  the  contractors  it  monitors  has  reduced 
the  knowledge  of  the  government  small  business  specialist  about  a 
specific  company,  and  increased  focus  on  year-over-year  increases  in  goal 
accomplishment  when  such  increases  may  not  be  possible. 


TRAINING  SHORTFALLS  OF  GOVERNMENT  SMALL  BUSINESS  SPECIALISTS 
AND  LARGE  BUSINESS  SBLOs 

Training  of  government  small  business  specialists  and  contractor 
Small  Business  Liaison  Officers  (SBLOs)  is  also  lacking.  Some  contractor 
and  government  personnel  cannot  differentiate  between  the  various 
types  of  small  business  plans— Comprehensive,  Master,  Commercial,  or 
Individual.  They  are  not  familiar  with  how  goals  data  should  be  calculated 
or  how  reports  on  goal  achievement  should  be  prepared  and  submitted. 
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Some  SBLOs  do  not  understand  how  to  report  small  business  dollars  if  a 
vendor  fits  more  than  one  small  business  size  category.  Some  agencies  do 
not  allow  the  use  of  Commercial  Plans  where  some  services— for  example, 
dredging  services— clearly  meet  the  definition  of  a  commercial  item.  This 
lack  of  knowledge  is  the  result  of  the  government  reducing  funding  for 
its  Regional  Councils  for  Small  Business  Education  and  Advocacy  and 
indifference  of  large  businesses  toward  the  Small  Business  Program.  Many 
large  businesses  doing  significant  business  with  the  federal  government 
simply  do  not  attend  small  business  meetings  chaired  by  the  DoD,  nor  do 
they  participate  in  local  SBLO  groups. 

So  what  can  be  done  to  make  the  federal  Small  Business  Program 
work  better? 


Recommendations 

Federal  agencies  should  re-focus  the  program  to  its  original  intent. 
If  changes  are  not  made  to  the  program,  continued  compliance  by  large 
businesses  may  wane,  and  the  very  existence  of  the  Small  Business 
Program  as  we  know  it  today  may  be  in  jeopardy.  In  the  Small  Business 
Act  of  1953,  Congress  voiced  its  conviction  that  the  federal  government 
should,  “aid,  counsel,  assist,  and  protect. ..the  interests  of  small  business 
concerns. ..to  insure  that  a  fair  proportion  of  the  total  purchases  and 
contracts  or  subcontracts  for  property  and  services  for  the  government... 
be  placed  with  small  business  enterprises.”  The  federal  Small  Business 
Program  can  more  effectively  meet  the  intent  of  the  Small  Business  Act  of 
1953  by  making  changes  to  the  program  so  it  truly  benefits  small  business 
manufacturers  and  service  providers,  does  not  negatively  affect  the 
supply  chain  of  large  businesses,  and  helps  ensure  that  the  federal  buyer 
gets  quality  products  at  fair  and  reasonable  prices. 

The  following  four  recommendations,  if  implemented,  can  be  the  recipe 
for  continued  success  necessary  to  energize  the  federal  government  Small 
Business  Program. 

1.  Reduce  employee  count  or  revenue  ceilings  in  North  American 
Industry  Classification  System  (NAICS)  size  standards. 

2.  Allow  large  businesses  to  create  small  business  plans  based  on 
subcontracting  opportunities  after  they  conduct  a  comprehensive 
Make-or-Buy  analysis  for  a  particular  solicitation. 

3.  Assign  DCMA  small  business  specialists  the  monitoring  of  large 
businesses  by  geographic  proximity. 

4.  Take  advantage  of  the  expertise  within  Procurement  Technical 
Assistance  Centers  (PTACs). 
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Recommendation  1.  The  SBA,  in  conjunction  with  the  Office  of  Management 
and  Budget  (OMB),  should  re-examine  how  employee  count  or  annual 
revenue  ceilings  are  determined  for  the  various  NAICS  codes.  The  goal 
should  be  to  create  small  business  size  ceilings  that  are  reflective  of  the 
size  of  most  small  businesses— 500  to  1,000  employees  is  simply  too  large 
for  the  small  business  ceiling  of  most  NAICS  codes.  The  Department  of 
Health  and  Human  Services  Web  site  states  that  90  percent  of  all  small 
businesses  in  the  United  States  employ  fewer  than  20  employees.  When  a 
20-person  small  business  competes  with  a  1,000-person  small  business,  it 
may  not  be  a  true  competition  between  two  small  businesses. 

Recommendation  2  First,  allow  large  businesses  to  submit  small  business 
plans  based  on  their  internal  capabilities  and  documented  determination 
regarding  outsourcing.  When  preparing  the  RFP,  do  not  include  small 
business  plan  goals  in  the  Section  M,  Evaluation  Factors  for  Award 
criteria.  Subcontracting  opportunities  may  be  very  different  from  one 
large  business  to  another.  Because  a  large  business  identifies  higher 
small  business  goals  does  not  make  that  plan  better  than  another  large 
business  that  identifies  smaller  goals.  Plans  may  be  very  different  from 
large  business  to  large  business,  but  still  represent  maximum  practicable 
opportunity  for  small  businesses  to  participate  in  contract  performance 
consistent  with  the  management  plan  of  the  large  business.  By  including 
small  business  plan  goals  as  a  criterion,  one  increases— needlessly,  in  my 
view— the  complexity  of  the  evaluation  and  the  possibility  of  botching  the 
source  selection.  Grading  one  small  business  plan  "better”  than  another 
without  taking  into  consideration  the  makeup  and  business  model  of  the 
large  business  could  also  lead  to  protests  after  award  (GAO,  2007)  and 
jeopardize  timely  support  of  the  warfighter. 

Second,  do  not  dictate  small  business  goals  in  solicitations.  Dictating 
goals  does  not  acknowledge  that  goal  identification  is  the  responsibility  of 
each  large  business  based  on  its  subcontracting  opportunities. 

Third,  if  goals  do  not  meet  the  Congressional  goal  mandates  for 
various  categories  of  small  business,  so  be  it.  Large  businesses  should  not 
be  forced  to  meet  congressionally  mandated  goals  if  the  subcontracting 
opportunities  do  not  warrant  such  goals. 

Large  business  SBLOs  have  a  multi-faceted  job  description,  differing 
in  some  ways  from  company  to  company.  However,  if  the  large  business 
SBLOs  are  doing  their  job  effectively,  they  should  be  making  sure  company 
employees— especially  purchasing  department  buyers— fully  understand 
the  government  Small  Business  Program  and  the  associated  buyer 
responsibilities  to  provide  maximum  practicable  opportunity  for  small 
businesses  to  compete  for  subcontracting  requirements.  SBLOs  should 
also  keep  abreast  of  changing  Small  Business  Program  requirements, 
whether  they  involve  a  change  in  mandated  goals  or  a  change  in  reporting, 
such  as  a  transition  from  paper  reports  to  electronic  reports. 
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In  years  past,  the  large  business  SBLOs  kept  abreast  of  changing 
requirements  by  attending  quarterly  or  semiannual  meetings  with  other 
large  businesses  in  their  immediate  geographic  area  as  part  of  a  large 
business  SBLO  group.  Such  groups  usually  included  participation  by  a 
small  business  specialist  from  the  DCMA.  it  was  this  interface  between 
large  business  SBLOs  and  DCMA  small  business  specialists  that  kept 
all  parties  informed  about  the  Small  Business  Program.  The  DCMA 
reorganized  its  small  business  specialists  in  2005.  This  reorganization 
eliminated  geographic  proximity  of  the  DCMA  small  business  specialists 
and  the  large  businesses  they  monitored,  resulting  in  less  communication 
and  less  face-to-face  interface. 

Recommendation  3.  Re-orient  DCMA  small  business  specialists  so  they  are 
in  geographic  proximity  to  the  large  businesses  they  monitor.  This  re¬ 
orientation  will  result  in  better  oversight  of  large  business  compliance  with 
the  intent  of  the  Small  Business  Program. 

Many  agencies  and  associations— some  funded  by  the  federal 
government,  some  funded  by  state  governments— promote  small 
businesses  selling  to  the  federal  government.  A  myriad  of  companies  is  also 
focused  on  some  part  of  the  small  business  market.  These  organizations 
include  the  National  Association  of  Minority  Contractors  (NAMC),  National 
Association  of  Women  Business  Owners  (NAWBO),  the  Office  of  Women’s 
Business  Ownership  (OWBO),  The  Center  for  Veterans  Enterprise  (VetBiz), 
the  National  Veteran-Owned  Business  Association  (NaVOBA),  Minority 
Business  Development  Agency  (MBDA),  and  the  Latin  Business  Association 
(LBA)  to  name  a  few.  The  problem  with  all  of  these  organizations  is  their 
inherent  focus  on  their  own  particular  category  of  small  business 

Yet,  one  organization,  Procurement  Technical  Assistance  Centers 
(PTACs),  stands  out  from  the  rest  because  PTACs  look  at  the  bigger 
picture  instead  of  the  flavor-of-the-month  mindset  that  places  emphasis 
with  women-owned  firms  today,  but  with  veteran-owned  firms  tomorrow. 
PTACs,  to  the  contrary,  work  effectively  with  all  small  businesses, 
regardless  of  the  small  business  type,  in  helping  them  make  contact  with 
large  businesses  or  federal  buying  agencies. 

Authorized  in  1985  by  Congress,  the  Procurement  Technical  Assistance 
Program  (PTAP)  strives  to  increase  the  number  of  proficient  businesses 
engaging  in  the  government  marketplace.  PTACs  often  reflect  the 
communities  and  areas  in  which  they  serve,  so  they  vary  in  size  and  shape. 
A  small  percentage  of  PTACs  are  administered  by  state  governments,  while 
others  work  in  partnership  with  community  colleges,  universities,  local 
economic  development  corporations,  or  other  institutions  in  the  local  area. 

Recommendation  4  Emphasize  to  large  businesses,  small  businesses,  and 
federal  buyers  that  PTACs  should  be  the  focal  point  for  small  business 
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vendor  outreach.  Emphasize  to  small  businesses  that  PTACs  are  the  best 
resource  for  information  on  doing  business  with  the  federal  government. 
De-emphasize  any  focus  on  “one  trick  pony”  associations  and  agencies  so 
the  federal  Small  Business  Program  is  more  in  line  with  the  original  intent 
of  the  Small  Business  Act  of  1953— to  help  small  businesses. 


Conclusions 

If  the  federal  Small  Business  Program  is  enforced  from  the  perspective 
of  its  original  intent,  goal  achievement  for  the  sake  of  goal  achievement 
will  be  de-emphasized,  and  the  recommendations  identified  in  this  treatise 
will  be  seriously  considered.  If  these  steps  are  taken,  small  businesses 
should  continue  to  prosper  in  the  federal  marketplace  and  receive  a  fair 
proportion  of  government  contracts.  Additionally,  the  American  taxpayer 
will  see  better  use  of  taxpayer  dollars.  These  actions,  if  enforced,  will  mark 
a  return  to  the  original  objectives  of  the  Small  Business  Act  of  1953. 
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ENDNOTES 

1.  Prior  to  Pub.  L.  95-507,  minority  businesses  were  defined  as  socially  or  economically 
disadvantaged  small  businesses.  According  to  a  Congressional  Report  at  the  time,  the 
change  from  “or”  to  “and”  was  to  prevent  the  increasing  number  of  “front”  companies— 
companies  posing  as  minority  businesses  but  controlled  by  non-minorities. 

2.  This  setaside  was  rescinded  in  1996. 

3.  FAR  6.202,  Establishing  or  Maintaining  Alternative  Sources,  establishes  or  maintains  an 
alternative  source  if  agency  head  determines  doing  this  will  also  result  in  reduced  overall 
costs;  or  is  in  the  interest  of  national  defense;  or  ensures  continuous  availability  of  a 
reliable  source;  or  fulfills  a  statutory  requirement  related  to  small  business  concerns;  or 
only  one  source  will  satisfy  agency  requirements. 
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BUILDING  ON  A  LEGACY: 

RENEWED  FOCUS  ON 
SYSTEMS  ENGINEERING  IN 
DEFENSE  ACQUISITION 


f  Mary  C.  Redshaw 


This  article  examines  the  evolving  model  used  to  describe 
the  systems  engineering  process  in  Defense  Acquisition 
University  (DAU)  courses.  As  implied  in  the  title,  discussion 
topics  reflect  both  the  legacy  and  current  focus  of  systems 
engineering  within  the  Department  of  Defense  (DoD).  The 
first  two  sections  provide  a  historical  context  of  the  systems 
engineering  discipline  and  outline  the  evolution  of  process 
models  and  terminologies  used  to  describe  process  activi¬ 
ties  within  DoD.  The  last  two  discussion  sections  describe 
interactions  among  the  technical  processes  and  technical 
management  processes,  and  analyze  the  implications  of 
systems  engineering  terminology  changes  introduced  with 
updates  in  defense  acquisition  guidance  released  in  June 
of  2009. 
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Keywords:  Defense  Acquisition,  Systems  Engineering, 
Technical  Process,  Technical  Management,  Process 
Mode / 
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In  2004,  Department  of  Defense  (DoD)  officials  initiated  efforts  to 
revitalize  systems  engineering  practices  in  defense  acquisition  programs. 
Acting  in  his  role  as  the  Defense  Acquisition  Executive,  Michael  Wynne 
(2004)  issued  a  policy  memorandum  that  stressed  the  need  “to  drive 
good  systems  engineering  practices  back  into  the  way  we  do  business” 
(p.  2).  That  statement  highlighted  an  assessment  that  revitalization  efforts 
would  build  on  a  legacy  of  proven  processes  and  practices  first  formalized 
to  support  defense  acquisition  programs  in  the  past.  Terminologies  and 
models  describing  the  systems  engineering  process  continue  to  evolve. 
However,  fundamental  aspects  of  the  discipline  have  not  changed  since 
DoD  released  the  first  systems  engineering  standard  (DoD,  1969). 

The  continuing  need  for  systems  engineering  is  driven  by  the  increasing 
technical  complexity  and  development  costs  of  defense  acquisition 
programs.  Programs  developing  complex  systems  exhibit  the  same 
features  that  led  to  the  need  to  formalize  the  systems  engineering  process 
in  the  first  place,  as  noted  in  an  early  text  published  by  the  Defense  Systems 
Management  College  (DSMC,  1986).  Many  acquisition  programs  involve 
large,  geographically  dispersed  design  teams,  numerous  subsystems 
under  concurrent  development,  severely  constrained  development  time, 
and  incorporation  of  advanced  technologies. 


Purpose 

This  article  examines  the  evolving  systems  engineering  process  model 
taught  as  part  of  Defense  Acquisition  University  (DAU)  courses.  One  can 
gain  new  perspectives  on  systems  engineering  process  interactions  by 
tracing  the  model’s  evolution  over  time.  This  article  will  provide  a  historical 
context  of  the  systems  engineering  discipline  in  DoD,  outline  the  evolution 
of  process  models  and  terminologies  used  in  DSMC  and  DAU  courses,  and 
analyze  the  implications  of  terminology  changes  introduced  in  the  Interim 
Defense  Acquisition  Guidebook  (Interim  DAG)  released  by  the  Office  of 
the  Secretary  of  Defense  (OSD)  in  2009. 


Historical  Context 

According  to  the  International  Council  on  Systems  Engineering 
(INCOSE,  n.d.),  the  term  systems  engineering  was  first  used  at  Bell 
Telephone  Laboratories  in  the  early  1940s.  Interest  in  the  systems 
engineering  discipline  grew  during  World  War  II  when  project  managers 
and  engineers  oversaw  the  development  of  capital  ships,  aircraft,  and 
weapons  systems  (National  Research  Council,  2008).  Use  of  systems 
engineering  practices  increased  following  World  War  II  as  government 
programs  leveraged  an  array  of  new  technologies  in  developing  computer 
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systems,  command  and  control  centers,  telecommunications,  ballistic 
missiles,  missile  defense  systems,  and  spacecraft.  The  coordination 
of  development  teams  employing  thousands  of  engineers  integrating 
multiple  subsystems  drove  the  need  to  formalize  the  methods  for  delivering 
useful,  reliable  systems  (DSMC,  1986;  National  Research  Council,  2008). 


FORMALIZING  THE  DISCIPLINE 

Because  of  the  department’s  role  in  acquiring  and  developing 
large-scale,  complex  systems,  defense  acquisition  managers  led  the 
way  in  codifying  the  systems  engineering  process— beginning  with  the 
publication  of  Military  Standard  499  (MIL-STD-499).  The  baseline  version 
of  MIL-STD-499  was  approved  for  trial  use  by  U.S.  Air  Force  developmental 
agencies  and  “for  possible  conversion  to  a  fully  coordinated  document 
mandatory  for  use  by  all  Department  of  Defense  Agencies”  (DoD,  1969, 
cover).  The  baseline  MIL-STD-499  documented  the  first  formal  consensus 
standard  governing  the  systems  engineering  community  of  practice. 
Department  officials  approved  a  subsequent  revision  of  the  military 
standard  (MIL-STD-499A)  for  Air  Force  use  only  (DoD,  1974).  However, 
MIL-STD-499A  quickly  became  the  de  facto  systems  engineering  standard 
for  many  defense  acquisition  programs. 

During  the  early  1990s,  DoD’s  systems  engineering  standard  underwent 
another  review  cycle.  Two  parallel  (but  opposing)  actions  impacted  what 
was  then  the  only  documented  standard  for  systems  engineering.  Both 
actions  unfolded  under  the  banners  of  defense  acquisition  reform. 


THE  LOSS  OF  A  STANDARD 

The  Air  Force  Materiel  Command  sponsored  a  joint  working  group 
comprised  of  representatives  from  OSD,  the  Services,  and  industry 
organizations.  The  working  group  formed  to  review  and  revise  MIL-STD- 
499A  for  use  by  all  DoD  components,  federal  agencies,  and  commercial 
organizations.  Members  of  the  joint  committee  actively  solicited  inputs 
from  a  wide  array  of  organizations  and  circulated  a  coordination  draft  of 
the  revised  standard  (MIL  STD  499B)  to  reviewers  in  government,  industry, 
and  academia  in  1992.  The  foreword  of  the  final  coordination  draft  of  MIL- 
STD-499B  (DoD,  1994)  outlined  the  focus  of  the  revised  standard.  The 
purpose  of  the  new  standard  was  to  define  a  comprehensive,  executable 
process  that  would  result  in  optimal  system  solutions  while  meeting  cost, 
schedule,  and  performance  objectives.  According  to  its  drafters,  the 
standard  process  would  be  applicable  in  all  phases  of  system  development 
and  could  be  tailored  to  the  size  and  complexity  of  any  effort.  The  drafters 
also  claimed  that  the  revised  standard  would  achieve  key  DoD  acquisition 
reform  efforts  to  encourage  innovation  in  products  and  practices;  to 
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better  integrate  requirements  through  multi-disciplinary  teamwork;  to 
increase  teamwork  and  cooperation  within  the  government  and  industry; 
and  to  reduce  the  time  needed  to  acquire  products  and  services  (DoD, 
1994).  Stakeholders  who  participated  in  the  development  and  review  of 
MIL-STD-499B  hailed  the  document  as  a  true  consensus  standard. 

However,  the  revised  standard  was  never  approved  by  DoD  officials 
due  to  another  acquisition  reform  initiative  that  emphasized  use  of 
commercial  standards  over  government  standards.  Defense  Secretary 
William  Perry  (1994)  issued  a  policy  memorandum  barring  the  use  of 
military  specifications  and  standards  on  DoD  acquisition  programs. 
Exceptions  to  the  new  policy  required  a  written  waiver  from  the  program’s 
milestone  decision  authority.  As  a  result,  the  final  draft  of  MIL-STD-499B 
was  never  approved  for  DoD  use,  and  MIL-STD-499A  was  cancelled 
without  replacement  in  1995. 


A  PROLIFERATION  OF  STANDARDS 


Because  no  commercial  systems  engineering  standards  existed, 
two  U.S.  standards  bodies  used  MIL-STD-499B  as  the  starting  point  for 
developing  and  releasing  their  own  standards  in  1994.  The  Electronic 
Industries  Association  (EIA,  1994)  issued  an  interim  standard  (EIA/ 
IS-632)  developed  by  a  working  group  of  participants  from  industry 
associations,  INCOSE,  and  DoD.  The  new  standard  outlined  a  consensus 
process  intended  for  use  by  commercial  enterprises,  government 
agencies,  and  defense  contractors.  Similarly,  the  Institute  of  Electrical 
and  Electronics  Engineers  (IEEE,  1994)  released  a  systems  engineering 
standard  (IEEE  1220-1994)  for  trial  use  by  industry  organizations.  In  turn, 
these  standards  underwent  subsequent  diverging  revisions  that  formed 
the  basis  for  a  proliferation  of  organizational  process  guides.  Arguably, 
and  as  a  direct  result  of  Perry’s  (1994)  memorandum  bar  ring  use  of  military 
standards,  the  practice  of  systems  engineering  (and  the  related  field 
of  software  engineering)  became  increasingly  fragmented  within  DoD 
and  across  departments  and  agencies  due  to  the  use  of  proliferating 
industry  standards,  process  improvement  frameworks,  and  organization- 
specific  guides  and  handbooks.  The  organization  that  first  codified  the 
discipline  now  found  itself  without  a  standard  governing  its  systems 
engineering  practices. 


DoD'S  STANDARDIZED  TERMINOLOGY 

Subsequent  to  the  2003  release  of  major  revisions  to  policy  documents 
governing  defense  acquisition  management,  OSD  (2004)  released  the 
first  (baseline)  version  of  the  Defense  Acquisition  Guidebook  (DAG).  The 
DAG  outlined  discretionary  best  practices  for  the  acquisition  workforce- 
including  a  chapter  devoted  to  systems  engineering.  Overtly  recognizing 
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that  “many  systems  and  software  engineering  process  models  and 
standards  use  different  terms  to  describe  the  processes,  activities,  and 
tasks  within  the  systems  engineering  and  other  life  cycle  processes"  (OSD, 
2004,  1  4. 2. 2. 2),  the  DAG  outlined  eight  technical  management  processes 
and  eight  technical  processes  to  be  applied  throughout  the  life  cycle  of 
DoD  acquisition  programs. 

Presumably  in  an  attempt  not  to  endorse  or  specify  a  particular 
industry  standard,  the  authors  of  the  baseline  DAG  chose  not  to  represent 
the  16  generic  systems  engineering  processes  in  a  model.  Instead,  the 
DAG  described  typical  phase-specific  activities,  with  a  different  graphical 
depiction  accompanying  the  descriptions  for  each  phase  of  the  life  cycle. 
The  same  phase-specific  graphical  depictions  also  appeared  in  the 
technical  portion  of  the  2004  (and  subsequent)  versions  of  the  Integrated 
Defense  Acquisition,  Technology,  and  Logistics  Life  Cycle  Management 
Framework—  commonly  referred  to  as  the  Watt  Chart  (DAU,  2004).  The 
technical  portion  of  the  Wall  Chart  included  activities  related  to  systems 
engineering,  test  and  evaluation,  and  supportability— with  no  correlation 
to  the  16  systems  engineering  processes  described  in  the  DAG. 

Following  a  2008  revision  to  DoD  Instruction  5000.02  governing  the 
Operation  of  the  Defense  Acquisition  System  (DoD,  2008),  the  revised 
Interim  DAG  (OSD,  2009)  was  posted  to  DAU’s  Acquisition  Community 
Connection  Web  site  the  following  year.  The  number  of  generic  systems 
engineering  processes  described  in  the  new  Interim  DAG  remained 
the  same:  eight  technical  management  processes  and  eight  technical 
processes.  Flowever,  three  of  the  technical  process  names  changed— 
indicating  that  DoD’s  “standardized  process  terminology”  (OSD,  2009, 
1 4.2.3)  had  evolved  in  alignment  with  revisions  to  the  international  standard 
issued  jointly  by  the  International  Organization  for  Standardization  and 
the  International  Electrotechnical  Commission  (ISO/IEC  15288:2008). 


An  Evolving  Systems  Engineering  Process  Model  for  DoD 

Instructors  at  DSMC  (and  later  at  DAU)  had  used  variations  of  the  MIL- 
STD-499  systems  engineering  process  model  to  teach  systems  engineering 
principles  and  practices  to  members  of  the  acquisition  workforce  since 
1974  (Schmidt  &  Crisp,  2006).  The  university’s  courses  still  included  the 
legacy  systems  engineering  process  model  when  OSD  officials  released 
the  baseline  DAG  in  2004.  The  model  used  by  DAU  faculty  members  to 
support  discussion  of  the  systems  engineering  process  evolved  in  recent 
years  with  changes  introduced  in  the  baseline  DAG  (OSD,  2004)  and 
subsequent  updates  in  the  Interim  DAG  (OSD,  2009). 
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LEGACY  MODEL 

A  depiction  of  the  legacy  systems  engineering  process  model  appears 
in  Figure  1.  The  legacy  model  has  several  advantages.  One  advantage  is 
an  elegant  simplicity  that  lends  itself  to  describing— and  understanding- 
essential  elements  of  the  systems  engineering  process.  That  simplicity 
facilitated  instruction  and  learning  while  conveying  some  of  the 
complexities  of  the  systems  engineering  problem-solving  methodology. 
The  legacy  model  depicts  three  primary,  sequential  design  process  steps: 
requirements  analysis,  functional  analysis  and  allocation,  and  synthesis. 
Additionally,  the  model  portrays  an  oval  shape  entitled  systems  analysis 
and  control  that  represents  technical  management  activities  and  tools  that 
support  all  three  primary  design  process  steps.  At  a  high  level,  the  model 
captures  the  top-down  application  of  the  design  steps,  their  interfaces 
with  technical  management  activities,  and  iterative,  recursive  loops 
between  process  pairs  that  ensure  all  system  requirements  are  completely 
defined,  traced,  and  verified. 

FIGURE  1.  LEGACY  (MIL-STD-499B)  PROCESS  MODEL 

V  Needs,  Objectives,  Requirements 

►  Mission,  Constraints,  Environment 

^  Measures  of  Effectiveness 

►  Technology  Base 

►  Output  from  Prior  Development 


►  System/Configuration/ 

Item  Configuration 

►  Specifications  and  Baselines 


However,  the  legacy  model  also  has  disadvantages.  One  disadvantage 
is  the  failure  to  elaborate  the  systems  analysis  and  control  portion  of 
the  model.  Another  disadvantage  is  that  the  verification  loop  does  not 
highlight  the  importance  of  test  planning,  testing,  and  evaluation  of  results 
as  integral  parts  of  the  product  development  process.  Perhaps  the  latter 
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disadvantage  is  one  of  the  reasons  why  variations  of  V-shaped  models  that 
explicitly  show  test-related  activities  have  become  prevalent  depictions  of 
the  systems  engineering  process.  The  “V”  form  (or  Vee )  “most  accurately 
represents  system  evolution  from  the  perspective  of  decomposition  and 
integration  activities”  (Forsberg,  Mooz,  &  Cotterman,  2005,  p.  109).  Of 
particular  note,  the  first  international  systems  engineering  standard  (ISO/ 
IEC  15288:2002)  employed  a  V-shaped  process  model. 

With  the  introduction  of  the  new  process  terminologies  in  the  baseline 
DAG  and  a  revised  Wall  Chart  in  2004,  instructors  teaching  systems 
engineering  principles  in  DAU  courses  faced  a  quandary.  Lesson  materials 
contained  the  legacy  systems  engineering  model,  but  that  model  did 
not  match  the  descriptions  of  the  standardized  technical  management 
processes  and  technical  processes  endorsed  by  OSD  or  the  depictions 
of  the  phase-specific  technical  activities  in  the  DAG  and  the  Wall  Chart. 
Under  normal  circumstances,  the  courses  in  DAU’s  career  field  curricula 
are  updated  to  reflect  changes  in  policy  as  soon  as  possible  after  those 
changes  occur.  In  this  case,  however,  course  developers  at  DAU  planned 
extensive  changes  to  selected  courses  as  part  of  a  systems  engineering 
revitalization  initiative  sponsored  by  the  Systems  and  Software  Engineering 
Directorate  within  OSD.  The  Defense  Acquisition  Executive  (Wynne,  2004) 
challenged  educational  leaders  at  DAU  to  “reinvigorate”  (p.  2)  systems 
engineering  training.  In  response,  the  university’s  administrators  initiated 
a  complete  makeover  of  the  systems  engineering  curriculum. 

As  part  of  the  effort  to  revise  the  Systems  Planning,  Research, 
Development,  and  Engineering  (SPRDE)  curriculum,  one  of  DAU’s  course 
managers  submitted  a  white  paper  (Redshaw,  2004)  to  the  SPRDE 
performance  learning  director  at  the  university’s  headquarters.  Redshaw’s 
white  paper  outlined  a  proposed  unified  approach  to  developing  the 
replacement  for  the  course  that  she  managed.  The  white  paper  included 
descriptions  and  graphics  of  two  models  Redshaw  proposed  to  use  in  the 
new  course  to  portray  the  eight  technical  processes  and  eight  technical 
management  processes  described  in  the  DAG. 


THE  HIERARCHICAL  VEE  MODEL 

One  of  the  models  in  Redshaw’s  white  paper  (2004)  appears  in  Figure 
2.  The  model  portrays  the  technical  management  processes  in  a  V-shaped 
pattern  (or  Vee)  superimposed  on  a  notional  organizational  hierarchy. 
The  Vee  shape  was  adapted  from  the  international  systems  engineering 
standard  (ISO/IEC,  2002).  The  organizational  hierarchy  was  adapted 
from  a  framework  developed  by  Kossiakoff  and  Sweet  (2003).  The  white 
paper  explicitly  correlated  the  left-hand  and  right-hand  activities  in  the 
Vee  to  the  three  primary  processes  and  the  verification  loop  in  the  legacy 
process  model.  The  left-hand  side  of  the  Vee  captured  the  top-down 
design  process;  the  right-hand  side  reflected  the  design  implementation, 
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FIGURE  2.  HIERARCHICAL  VEE  MODEL 
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integration ,  verification,  validation,  and  transition  activities  described  in 
the  DAG.  Redshaw’s  hierarchical  depiction  of  the  systems  engineering 
technical  processes  was  included  in  subsequent  updates  of  the  DAU 
Program  Managers  Tool  Kit,  with  the  graphic’s  last  appearance  in  the  14th 
edition  (DAU,  2008). 

The  hierarchical  Vee  depiction  provides  a  powerful  visualization  of 
interfaces  among  key  stakeholders  and  domains  of  responsibility  in  the 
acquisition  process  as  well  as  "process  linkages”  (DAU,  2008,  p.  78) 
between  the  steps  on  the  left-hand  and  right-hand  sides  of  the  Vee.  The  top 
portion  highlights  process  and  organizational  interfaces  between  decision 
authorities  and  the  project  team  developing  the  system.  Depending  on 
the  project  or  the  area  of  the  system  hierarchy  under  consideration,  the 
primary  stakeholders  may  include  the  users,  project  sponsors,  senior 
decision  makers,  project  or  engineering  managers  at  a  higher  level  in  the 
system  hierarchy,  or  the  acquiring  organization  in  an  acquirer-supplier 
contract  agreement. 

The  first  technical  process  described  in  the  baseline  DAG  (OSD,  2004) 
was  requirements  development.  At  the  system  level,  Redshaw’s  (2004, 
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2006)  hierarchical  Vee  model  portrayed  requirements  development  as 
two  subordinate  processes  occurring  at  the  organizational  intersection  of 
the  project’s  development  team  with  the  Acquisition  Management  System 
and  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS). 

The  outputs  of  the  first  subordinate  process —stakeholder  requirements 
definition— include  the  capabilities  documents  that  govern  technology 
development,  system  development,  and  production  as  well  as  baseline 
agreements  between  decision  authorities  and  the  development  team  that 
establish  project  scope  and  deliverables.  The  concept  of  organizational 
interfaces  is  particularly  important  in  a  system-of-systems  or  net-centric 
context.  The  systems  engineer  responsible  for  developing  a  system  or 
subsystem  must  view  it  from  the  outside,  or  within  the  framework  of  the 
larger  architecture  in  which  the  system  is  intended  to  operate.  “To  achieve 
good  results,  systems  engineers  involve  themselves  in  nearly  every  aspect 
of  a  project,  pay  close  attention  to  interfaces  where  two  or  more  systems 
or  system  elements  work  together,  and  establish  an  interaction  network 
with  stakeholders  and  other  organizational  units  of  the  enterprise” 
(Haskins,  Forsberg,  &  Krueger,  2007,  p.  41).  In  addition  to  the  interface 
between  the  JCIDS  and  acquisition  domains,  translating  users’  needs  into 
technical  requirements  involves  interfaces  between  the  acquiring  agency 
and  the  supplier’s  organization,  and  between  the  systems  engineer  and 
other  engineering  managers  at  various  levels  in  the  system  hierarchy. 

The  second  subordinate  process  is  requirements  analysis— a  direct 
and  deliberate  correlation  to  the  first  process  step  in  the  legacy  systems 
engineering  process  model.  Anyone  familiar  with  the  legacy  model  readily 
can  see  the  correlation  of  its  remaining  two  design  process  steps  ( functional 
analysis  &  allocation  and  synthesis')  with  two  technical  processes  described 
in  the  baseline  DAG  ( logical  analysis  and  design  solution,  respectively). 

The  component  level  of  design  occurs  at  the  interface  of  the  systems 
engineering  and  specialty  engineering  domains  in  the  system  hierarchy. 
As  the  detailed  design  is  finalized  for  implementation,  the  systems 
engineer  and  component  design  specialists  identify  and  resolve  technical 
issues  and  select  workable,  producible  solutions  that  will  not  jeopardize 
the  overall  system  design,  capabilities,  performance,  or  suitability 
(Kossiakoff  &  Sweet,  2003).  Implementation  of  system  elements  occurs 
within  specialty  domains  (Schmidt  &  Crisp,  2006).  However,  the  systems 
engineer  monitors  the  outcomes  because  they  affect  the  overall  design, 
performance,  cost,  and  schedule.  Similarly,  the  systems  engineer  monitors 
the  outcomes  of  integration,  verification,  and  validation  with  an  eye  to 
potential  discrepancies  requiring  design  modifications.  At  the  end  of  each 
development  phase,  project  managers  and  decision  authorities  review 
systems  engineering  outputs  during  the  transition  process  to  determine 
if  results  warrant  further  development,  production,  or  deployment  to 
operational  use. 
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FIGURE  3.  UPDATED  CSEP  MODEL 
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TECHNICAL  PROCESSES 

A  COMPREHENSIVE  SYSTEMS  ENGINEERING  PROCESS  (CSEP)  MODEL 

Redshaw’s  white  paper  (2004)  also  proposed  a  comprehensive 
systems  engineering  process  (CSEP)  model.  The  CSEP  model  depicted 
the  eight  technical  processes  operating  within  a  framework  governed  by 
the  eight  technical  management  processes.  The  author  refined  the  CSEP 
framework  over  time,  culminating  in  an  article  that  proposed  it  as  a  new 
model  for  DoD  systems  engineering  (Redshaw,  2006).  Faculty  members 
across  DAU  adopted  variations  of  the  CSEP  model  as  a  visual  aid  to 
explaining  the  systems  engineering  process  to  practitioners  in  various 
acquisition  career  fields.  An  updated  CSEP  model  appears  in  Figure  3. 


Process  Interactions 

The  updated  CSEP  model  in  Figure  3  incorporates  the  standardized 
terminology  in  the  Interim  DAG  that  OSD  released  in  2009.  The  latest 
revision  (as  this  article  goes  to  press)  of  the  Program  Managers  Tool  Kit 
(DAU,  2009)  included  a  similar  depiction  of  the  comprehensive  systems 
engineering  process.  While  terminologies  and  process  depictions  have 
evolved  over  time,  the  process  interactions  depicted  in  the  CSEP  model 
have  remained  essentially  the  same  as  those  implied  in  the  legacy  systems 
engineering  model. 
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TECHNICAL  PROCESS  INTERACTIONS 

Members  of  the  development  team  apply  the  technical  processes  at 
all  stages  of  development  to  elaborate  the  system,  generate  information 
for  decision  makers,  and  provide  starting  points  or  inputs  for  the  next 
level  of  development.  The  technical  processes  are  used  to  (a)  develop 
and  define  the  requirements  for  the  system  and  lower-level  configuration 
items;  (b)  transform  requirements  into  technical  product,  process,  and 
material  descriptions;  (c)  fabricate  system  elements;  (d)  assemble  system 
elements  into  higher-level  assemblies  and  end  products;  and  (e)  verify  and 
validate  system  products,  capabilities,  and  services  against  requirements 
established  at  each  level  in  the  system  hierarchy. 

The  V-shaped  model  highlights  some  of  the  important  characteristics 
of  the  technical  processes,  including  the  sequential  order  of  process 
completion.  The  left-hand  side  of  the  Vee  portrays  the  top-down  design 
that  occurs  as  requirements  are  allocated  progressively  from  the  system 
level  to  lower-level  elements  in  the  architecture  in  a  manner  consistent 
with  the  arrangement  of  the  design  process  steps  in  the  legacy  model. 
However,  the  V-shaped  model  explicitly  illustrates  the  bottom-up  design 
implementation  from  lowest  level  components  to  higher  assemblies  in  order 
to  integrate  the  complete  system,  verify  and  validate  that  all  requirements 
are  met,  and  transition  to  the  next  level  of  the  system  structure  or  to  the 
next  life  cycle  phase. 

In  addition  to  their  application  across  the  life  cycle,  the  technical 
processes  are  applied  at  different  levels  in  the  system  hierarchy  to  elaborate 
and  mature  the  system.  In  the  top-down  application  on  the  left-hand  side, 
measurable  criteria  are  documented  at  each  level  of  system  decomposition 
and  design— forming  the  basis  for  test  and  evaluation  during  bottom-up 
system  realization  on  the  right-hand  side.  Using  an  automotive  analogy, 
the  technical  processes  form  a  problem-solving  V-8  engine  that  is  applied 
throughout  the  life  cycle  to  ensure  complete  and  balanced  coverage  of 
input  and  derived  requirements  to  lower  elements  in  the  system  hierarchy. 
At  the  end  of  each  development  phase,  project  members  review  outputs 
and  evaluate  test  results  to  determine  if  all  products  meet  requirements. 
Decision  makers  determine  if  acquirer-supplier  agreements  are  met,  if 
further  system  development  and  maturation  is  warranted,  and  if  the  project 
is  ready  to  transition  to  the  next  planned  effort,  phase,  or  acquisition  life 
cycle  function  (such  as  production,  deployment,  or  operation). 


TECHNICAL  MANAGEMENT  PROCESS  INTERACTIONS 

The  technical  management  processes  in  the  CSEP  model  are  equivalent 
to  the  systems  analysis  and  control  portion  of  the  legacy  model.  Members 
of  the  development  team  apply  the  technical  management  processes 
to  establish  and  evolve  project  plans,  assess  actual  achievements  and 
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FIGURE  4.  OPERATION  OF  THE  TECHNICAL  MANAGEMENT 
PROCESSES 
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Technical  Management  Processes  are  used  to  manage  the  technical  development  of 
the  system,  including  its  supporting  or  enabling  products.  They  include:  Technical 
Planning,  Technical  Assessment  and  Decision  Analysis,  and  a  set  of  processes 
collectively  referred  to  as  Technical  Control  Processes.  These  include:  Requirements 
Management,  Interface  Management,  Risk  Management,  Configuration  Management, 
and  Technical  Data  Management. 


progress  against  those  plans,  evaluate  and  select  alternatives,  and  control 
project  execution.  Note  that  in  the  CSEP  model  the  technical  processes 
always  operate  within  the  encompassing  framework  of  the  technical 
management  processes.  While  the  technical  management  processes 
follow  no  explicit  order,  they  typically  interoperate  cyclically  as  shown  in 
Figure  4.  The  results  of  one  part  of  the  cycle  become  the  inputs  to  others. 

Collectively,  the  technical  management  processes  form  the  executive— 
or  control  logic— that  steers  system  development  to  meet  project  or  phase 
objectives.  Using  another  automotive  analogy,  the  technical  management 
processes  operate  together  as  a  rotary  engine.  These  processes  operate 
continuously  in  concert  with  one  another  to  support  and  control  the 
application  of  the  technical  processes,  balance  technical  and  business 
needs  of  all  stakeholders,  implement  project  plans,  and  respond  to 
unforeseen  events.  Documented  technical  project  plans  form  the  basis  for 
execution  and  assessment.  Team  members  continuously  assess  results  to 
determine  progress  in  meeting  project  plans  and  to  identify  the  need  for 
corrective  actions  or  additional  planning. 
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FIGURE  5.  EVOLVING  TERMINOLOGIES  REFLECT  EXPANDED 
FOCUS 


US 

C 

bp 

\n 

cu 

Q 

\ 

c 

cu 

E 

CL 

_o 

cu 

> 

cu 

Q 


Pre-2003  Policy 
Requirements 
Generation  System 


2003  Policy/JCIDS 

2004  baseline  DAG 


2008  Policy 

2009  Interim  DAG 


Synthesis 


mmmm 


Implementation,  Integration,  Verification, 
Validation,  Transition 


Technical  Planning,  Decision  Analysis,  Technical 
Assessment,  Risk  Management,  Requirements 
Management,  Configuration/Interface  Management 


y  Required  Capabilities 

►  Concept  of  Operations 

►  Support  Concept 

►  Baseline  Agreements 

^  Technologies 

►  Design  Considerations 
t  Constraints 

►  System  Specification 
^  External  Interfaces 

►  Functional  Baseline 

y  Functional  Architecture 

►  Item  Specifications 
^  Allocated  Baseline 

►  Physical  Architecture 

►  Internal  Interfaces 

►  Integration  Plan 


►  Component  Design 

►  Software  Design 

►  Initial  Product  Baseline 


New  terminologies  for  an  expanded  focus.  Recall  that  the  baseline  DAG 
(OSD,  2004)  introduced  eight  technical  processes  and  eight  technical 
management  processes.  Redshaw  (2004,  2006)  correlated  the  legacy 
systems  engineering  process  model  to  the  new  terminologies  in  the  DAG 
through  the  hierarchical  Vee,  depicting  the  technical  processes  and  a 
comprehensive  model  that  included  all  16  processes.  Redshaw  argued  that 
the  three  design  processes  applied  by  the  development  project  team  were 
the  same  in  both  models,  although  terminologies  had  changed  slightly  to 
reflect  that  actions  associated  with  the  JCIDS  process  provided  inputs  to 
govern  system  development.  Figure  5  shows  the  evolution  in  terminologies 
from  the  legacy  MIL  STD  499  systems  engineering  model  (prior  to  2003), 
the  baseline  DAG  (OSD,  2004),  and  the  Interim  DAG  (OSD,  2009). 

Figure  5  also  overlays  the  concept  of  hierarchical  domain 
responsibilities  with  notional  considerations  and  outcomes  in  all  three 
models.  Visually,  the  progression  in  Figure  5  suggests  a  key  concept 
about  the  role  of  systems  engineering  in  balancing  the  tension  between 
requirements  and  the  evolving  design.  "Systems  engineering  serves  as  the 
glue  that  binds  the  technical  solution  to  the  high-level  requirements  and 
maintains  the  program  baseline”  (Meier,  2008,  p.  67).  To  achieve  successful 
acquisition  outcomes,  stakeholders  in  all  domains  of  responsibility  must 
practice  disciplined  systems  engineering. 

By  categorizing  two  sets  of  processes,  the  drafters  of  the  baseline 
DAG  (OSD,  2004)  and  the  Interim  DAG  (OSD,  2009)  emphasized 
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another  instructional  point.  Systems  engineering  is  both  a  technical  and 
a  management  discipline,  and  acquisition  practitioners  must  apply  both 
sets  of  processes  in  tandem  throughout  the  system  life  cycle  (DSMC, 
1986).  Solid  technical  planning  is  the  starting  point  to  determine  how 
the  project  team  will  apply  the  systems  engineering  processes  in  a 
coordinated  fashion  in  each  phase  of  development.  Current  acquisition 
policy  prescribes  that  program  managers  embed  systems  engineering  in 
program  planning  (DoD,  2008). 

The  legacy  model  emphasized  the  importance  of  three  design 
processes  that— despite  the  changes  in  terminology— appear  among  the 
new  technical  processes.  These  three  steps  are  the  heart  of  the  technical 
aspect  of  systems  engineering  as  “the  translation  of  a  user’s  needs  into  a 
definition  of  the  system  and  its  architecture  through  an  iterative  process 
that  results  in  an  effective  design”  (National  Research  Council,  2008,  p.  1). 
Due  diligence  in  applying  these  first  three  process  steps  assures  a  robust 
design  with  sufficient  flexibility  and  adaptability  to  facilitate  successful 
completion  of  the  remaining  steps  and  the  project  (Meredith  &  Mantel, 
2000).  In  applying  the  design  steps,  stakeholders  explicitly  identify 
relationships,  requirements  interdependencies,  and  assessment  criteria 
tracked  throughout  system  development  (Meade  &  Farrington,  2008). 
When  applied  in  a  disciplined  manner  in  conjunction  with  the  technical 
management  processes,  the  design  steps  lay  the  groundwork  for  a  solid 
technical  solution. 

Using  the  updated  terminology  in  the  Interim  DAG  (OSD,  2009), 
stakeholder  requirements  definition  establishes  a  firm  baseline  for  system 
requirements  and  constraints  the  development  project  team  must  meet, 
thus  defining  project  scope.  During  requirements  analysis,  members  of  the 
project  team  examine  users'  needs  against  available  technologies,  design 
considerations,  and  external  interfaces  to  begin  translating  operational 
requirements  into  technical  specifications.  Architecture  design  entails 
developing  a  coherent  functional  architecture  to  achieve  required 
capabilities  across  scenarios  from  the  operational  concept;  developing  a 
physical  architecture,  internal  interfaces,  and  integration  plan;  synthesizing 
alternative  combinations  of  system  components;  and  selecting  the  optimal 
design  that  satisfies  and  balances  all  requirements  and  constraints.  The 
optimal  design  is  one  that  results  in  a  validated,  affordable  system  that  is 
operationally  effective  and  suitable. 

Summary 

The  legacy  model  formerly  used  in  DSMC  and  DAU  courses  traces  its 
genealogy  to  MIL-STD-499  (DoD,  1969,  1974,  1994),  which  was  the  first— 
and  for  26  years  the  only— documented  consensus  standard  for  the  systems 
engineering  discipline.  While  retaining  essentially  the  same  design  process 
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steps  and  attributes  of  the  legacy  systems  engineering  process  model  in 
Figure  1,  the  hierarchical  Vee  and  CSEP  models  offer  additional  valuable 
insight.  The  hierarchical  model  in  Figure  2  illustrates  interactions  among 
domains  of  responsibility  and  relationships  among  the  eight  technical 
processes.  The  CSEP  model  in  Figure  3  connotes  the  encompassing  and 
executive  nature  of  the  eight  technical  management  processes  described 
in  the  baseline  DAG  (OSD,  2004)  and  the  superseding  Interim  DAG  (OSD, 
2009).  The  V-shaped  pattern  of  the  technical  processes  in  Figure  2  and 
Figure  3  illustrates  a  sequential  order  of  application  to  achieve  top-down 
design  and  bottom-up  realization  of  the  system.  The  rotary  pattern  in 
Figure  4  depicts  a  continuing  cyclical  interaction  among  the  technical 
management  processes.  The  technical  management  processes  provide 
the  executive  logic  that  governs  and  controls  the  technical  problem¬ 
solving  methodology  in  the  V-8  engine. 

The  introduction  of  new  process  steps  in  the  baseline  DAG  (OSD, 
2004)  and  the  updated  Interim  DAG  (OSD,  2009)  highlight  the 
interaction  of  systems  engineering  in  all  aspects  of  development,  while 
the  categorization  of  two  sets  of  processes  emphasizes  that  systems 
engineering  is  both  a  technical  and  a  management  discipline.  Figure 
5  summarizes  the  evolution  of  the  terminologies  used  to  denote  key 
design  steps  in  the  systems  engineering  process.  Building  on  the  legacy 
of  the  standard  that  first  formalized  the  discipline  in  1969,  the  evolution 
in  terminologies  and  process  models  supports  the  increased  emphasis 
on  systems  engineering  throughout  the  life  cycle  and  in  all  domains  of 
responsibility.  As  emphasized  in  current  defense  acquisition  policy, 
achieving  successful  program  outcomes  requires  effective  acquisition 
management  that  reflects  a  disciplined  approach  to  systems  engineering. 
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OPEN  SYSTEMS: 

DESIGNING  AND 
DEVELOPING  OUR 
OPERATIONAL 
INTEROPERABILITY 

f  MAJ  James  Ash ,  USA  (Ret.)  and 
LTC  Willie  J.  McFadden  II,  USA  (Ret.) 

The  need  for  technological  innovation  in  the  U.S.  Army  is 
continually  increasing.  The  challenge  is  to  institute  a  "change 
paradigm”  that  will  allow  the  incorporation  of  new  tech¬ 
nology  into  existing  systems  to  address  current  and  future 
challenges,  within  fiscal  and  technological  constraints.  Open 
Systems  is  such  an  approach.  An  Open  Systems  environ¬ 
ment  facilitates  a  more  efficient  assimilation  of  technology. 
Furthermore,  Open  Systems  would  reduce  the  costs  of 
technology  integration  and  encourage  efforts  toward  inte¬ 
grated  training  and  operational  readiness,  using  standards 
and  protocols  across  our  nation’s  warfighting  enterprise. 
Various  goals  and  challenges  are  inherent  to  the  use  of  an 
Open  Systems  approach,  such  as  Transformation  Life  Cycle, 
interoperability,  physical  connectivity,  and  political  and  tech¬ 
nical  solutions,  which  are  described  herein. 


Keywords:  Open  Systems,  Open  Architecture, 
Architecture,  System,  System  of  Systems, 
Transformation  Life  Cycle 
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A  Challenged  Environment 

The  U.S.  Army  is  smaller  today  than  it  has  been  in  years  past,  yet  it 
takes  on  ever-increasing  demands  for  its  services.  Furthermore,  as  the 
Army’s  operational  tempo  increases,  associated  increases  in  procurement 
and  sustainment  costs  inevitably  escalate.  As  a  result,  warfighter  training, 
warfighter  planning,  and  real-time  warfighting  must  be  conducted  in  a 
more  seamless  and  integrated  fashion. 

Due  to  the  ever-changing  nature  of  warfare  and  its  accompanying 
operational  demands,  the  need  for  technological  innovation  is  continually 
increasing.  The  challenge  is  to  institute  a  “change  paradigm”— a 
new  perspective  that  will  allow  the  incorporation  of  new  technology 
(unmanned  systems,  intelligent  agents,  cyber  assets,  space  systems), 
within  the  boundaries  of  current  fiscal  and  technological  constraints— into 
existing  systems  to  address  or  resolve  many  of  the  challenges  discussed 
here  and  more. 


The  Open  Systems  Approach 

A  real  and  possible  solution  to  incorporate  new  technologies  into 
current  systems  is  for  the  Army  to  intensify  its  efforts  to  achieve  an  Open 
Systems  environment.  An  Open  Systems  (also  known  as  Open  Architecture) 
environment  would  facilitate  a  faster  and  smoother  assimilation  of 
technology.  Furthermore,  Open  Systems  would  also  reduce  the  costs  of 
technology  integration  and  would  encourage  efforts  toward  integrated 
training  and  operational  readiness,  using  standards  and  protocols  across 
our  nation’s  warfighting  enterprise.  The  flexibility  of  integrating  our 
systems,  via  open  architectures,  is  a  critical  component  to  our  Army’s 
force  modernization. 

The  idea  of  implementing  an  Open  Systems  approach  already  has  the 
support  of  the  Department  of  Defense  (DoD).  The  Office  of  the  Secretary 
of  Defense  established  the  Open  Systems  Joint  Task  Force  (OSJTF)  in  the 
mid-1990s,  and  its  charter  clearly  focused  all  Services  on  the  future  of  a 
Modular  Open  Systems  Approach. 

Understanding  Open  Systems  theory  and  how  it  relates  to  enhancing 
warfighting  efforts  is  an  important  responsibility  that  is  shared  between 
DoD  and  corporate  partners.  Before  beginning  the  development  of  specific 
solutions  through  the  OSJTF,  it  is  imperative  that  the  goals  and  strategies 
be  in  place.  This  is  a  challenging  issue  due  to  the  number  of  stakeholders 
involved  in  an  Army  Open  Systems  approach  (Table  1). 
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TABLE  1.  OPEN  SYSTEMS  ARCHITECTURE-ARMY  SIGNIFICANT 
STAKEHOLDERS 


1. 

OSJTF 

2. 

Army  G-8,  Army  G-3,  Army  G-6,  Headquarters, 

Department  of  the  Army 

3. 

Army  Materiel  Command  (AMC) 

4. 

Training  and  Doctrine  Command  (TRADOC) 

5. 

Weapon  System  Technical  Architecture  Working  Group 

6. 

U.S.  Army  Research,  Development,  and  Engineering  Command 

7. 

SEI  Carnegie  Mellon 

8. 

Original  Equipment  Manufacturers 

(i.e.,  Boeing,  General  Dynamics,  Raytheon,  Sikorsky,  etc.) 

CHARACTERISTICS  OF  OPEN  SYSTEMS 

Open  Systems  theory  is  a  comprehensive  model  that  describes  the 
elements  of  an  organization  and  their  dynamic  interrelationships  (Hanna, 
1988).  It  states  that  organizations  are  an  arrangement  of  elements  that 
have  interdependence  on  one  another. 

William  Pasmore,  a  leading  expert  in  systems  thinking,  writes  that 
“Systems  thinking  provides  guidance  and  direction  for  exploration 
of  an  organization  and  its  goals  for  change.  It  describes  the  complex 
relationships  between  people,  tasks,  and  technologies  and  helps  us  to  see 
how  these  can  be  used  to  enhance  organizational  performance”  (Pasmore 
&  Sherwood,  1978).  Additional  definitions  are  provided  in  Table  2. 

Open  Systems  theory  provides  an  important  foundation  for 
developing  a  comprehensive  Open  Systems  approach.  Interdependency 
through  connectivity  of  Open  Systems  theory  is  a  foundational  layer 
that  underpins  the  goals  of  Open  Systems.  However,  connectivity  is  not 
necessarily  hardwired  or  continuous;  rather,  it  may  be  established  through 
digital  means  when  appropriate  and  on  an  as-needed  basis. 


FURTHER  DEFINING  OPEN  SYSTEMS 

Open  Systems  are  about  the  entities,  their  relationship  patterns, 
boundaries  of  the  systems,  and  the  environment(s)  in  which  the  systems 
reside.  One  of  the  best  characterizations  of  an  Open  System  is  summarized 
by  the  frequently  paraphrased  statement:  If  you  put  20  people  in  a  room, 
you  can  find  at  least  20  different  definitions  for  Open  Systems. 

The  DoD’s  OSJTF  defines  Open  Systems  as  “a  system  that  employs 
modular  design,  uses  widely  supported  and  consensus-based  standards 
for  its  key  interfaces,  and  has  been  subjected  to  successful  validation 
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TABLE  2.  COMPARISON  OF  DEFINITIONS 


Agency  Institution 

Definition 

SEI 

A  system  that  implements  sufficient  open 
specifications  for  interfaces,  services,  and 
supporting  formats  to  (1)  enable  properly 
engineered  components  to  be  utilized 
across  a  wide  range  of  systems  with  minimal 
changes;  (2)  to  interoperate  with  other 
components  on  local  and  remote  systems; 
and  (3)  to  interact  with  users  in  a  style  that 
facilitates  portability. 

OSJTF 

A  system  that  employs  modular  design,  uses 
widely  supported  and  consensus-based 
standards  for  its  key  interfaces,  and  has 
been  subjected  to  successful  validation  and 
verification  tests  to  ensure  the  openness  of 
its  key  interfaces. 

Webopedia 

An  architecture  whose  specifications  are 
public.  This  includes  officially  approved 
standards  as  well  as  privately  designed 
architectures  whose  specifications  are  made 
public  by  the  designers.  The  opposite  of 
open  is  closed  or  proprietary. 

IEEE  POSIX  1003.0/D15 
as  modified  by 

Tri-Service  OSA 

Working  Group, 

Nov.  1995 

A  system  that  implements  sufficient  open 
specifications  for  interfaces,  services,  and 
supporting  formats  to  enable  properly 
engineered  components  to  be  utilized 
across  a  wide  range  of  systems  with  minimal 
changes.  An  open  system  is  characterized 
by  the  following: 

•  Well-defined,  widely  used,  non¬ 
proprietary  interfaces/protocols 

•  Use  of  principles  that  are  developed/ 
adopted  by  industrially  recognized 

standards 

•  Definition  of  all  aspects  of  system 

interfaces 

•  Explicit  provision  for  expansion  or 
upgrading. 
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and  verification  tests  to  ensure  the  openness  of  its  key  interfaces”  (Open 
Systems  Joint  Task  Force,  n.d.).  Further  definitions  of  an  Open  Systems 
approach  encompass  several  key  elements  and  ideas  associated  with 
Open  Systems.  Some  of  these  key  elements  are  established  industry 
protocols,  standards,  and  interfaces.  Table  3  also  addresses  Open  Systems 
components.  Additional  characteristics  of  Open  Systems  follow  (Open 
Systems  Joint  Task  Force,  n.d.): 

•  Use  of  developed,  adopted,  and  recognized  standards 

•  Well-defined,  widely  used,  non-proprietary  interfaces/ 
protocols 

•  Standing  governance  bodies  regulating  Open  Systems 
standards 


TABLE  3.  COMPONENTS  OF  OPEN  SYSTEMS  THEORY 


Component 

Explanation 

Entity 

A  system  entity  can  be  an  individual,  group, 
technology,  or  a  combination  that  comprises  the 
organizational  system. 

System  Boundary 

The  system  boundary  is  the  border  that 
delineates  it  from  other  systems  and  the 
environment.  It  is  permeable,  allowing  interaction 
between  the  system  and  its  environment. 

Properly  identifying  the  boundary  helps 
determine  the  complexity  of  the  organization’s 
policy  decision  and  ultimately  the  analysis.  This 
boundary  provides  the  contextual  environment 
that  the  policy  decision  will  affect. 

Pattern  of 

The  pattern  of  relationships  between  entities 

Relationships 

interconnects  all  entities  within  the  system,  but 

Between  Entities 

all  entities  do  not  have  to  connect  to  each  other. 

A  connection  or  relationship  does  not  have  to  be 
two-way. 

Environment 

The  local  environment  consists  of  entities 

or  systems  that  have  a  habitual  association 
and  critical  effect  on  the  system.  The  global 
environment  is  the  larger  environment  that 
encompasses  the  system.  It  includes  systems 
outside  the  parent  organization.  Analysts 
must  carefully  define  the  boundaries  of  local 
and  global  environments  so  as  not  to  invite 
unwarranted  complexity  or  overlook  important 
interactions  with  the  system. 
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Definition  of  all  aspects  of  system  interfaces  to  facilitate 
new  or  additional  systems  capabilities  for  a  wide  range 
of  application 

Explicit  provision  for  expansion  or  upgrading  through  the 
incorporation  of  additional  or  higher  performance  elements 
with  minimal  impact  on  the  system. 


GOALS  AND  CHALLENGES 

The  success  of  Open  Systems  depends  largely  on  defining, 
implementing,  and  satisfying  goals  at  hand.  The  goals  that  are  established 
to  accomplish  Open  Systems  must  be  evolutionary  in  nature  because 
of  the  magnitude  of  systems  and  the  dynamic  environment  of  the  DoD. 
The  OSJTF  charter  has  published  goals  that  apply  to  all  Services  (Open 
Systems  Joint  Task  Force,  n.d.). 

The  OSJTF  must  oversee  the  military  departments'  transitions  to 
Open  Systems-centered  acquisition  and  advise  acquisition  executives 
on  Open  Systems  implementation.  Also,  OSJTF  must  act  as  the  lead 
standardization  activity  for  Open  Systems  weapons  electronics  and  plan 
the  transition  of  this  role  to  a  permanent  activity.  It  must  also  coordinate 
and  support  DoD  participation  with  appropriate  industry  standards  bodies 
for  non-information  Technology  (IT)  standards.  For  IT  standards,  OSJTF 
will  support  the  executive  agent  in  developing  and  representing  the  DoD 
position. 

Other  OSJTF  goals  include  establishing  sources  of  training  in  Open 
Systems;  establishing  a  repository  that  facilitates  the  communication  of 
Open  Systems  ideas,  implementations,  techniques,  and  technologies; 
designating  appropriate  Open  Systems  standards  for  DoD  weapons 
systems  use;  and  coordinating  with  the  executive  agent  for  IT  standards 
and  forwarding  IT  standards  issues  to  the  executive  agent  for  resolution. 

Some  specific  points  from  the  OSJTF  charter  highlight  various 
challenges  that  the  Army  faces  as  it  works  to  implement  Open  Systems. 

•  Cost,  interoperability,  modularity,  technology  transparency, 
and  supportability  of  the  various  systems  create  significant 
management  demands. 

•  Current  efforts  are  still  somewhat  fragmented  and 
stovepiped,  relatively  narrow,  and  are  limited  primarily  to 
computers  and  bus  structures. 

•  The  air-,  land-,  and  sea-based  communities  have  too  little 
interaction. 

•  The  intended  foci  of  the  OSJTF  are  weapons  systems  and 
platforms,  not  Command,  Control,  Communications,  and 
Intelligence  (C3I)  systems,  communications  networks,  or 
non-real-time,  data-processing  functions. 
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Another  implicit  goal  of  Open  Systems  is  to  integrate  hardware, 
software,  systems,  and  people  within  the  live,  virtual,  and  constructive 
training  and  warfighting  environments.  However,  the  OSJTF  will  not 
attempt  to  force  the  use  of  common  hardware  everywhere;  rather,  it  will 
seek  to  standardize  to  each  unique  need  while  retaining  the  advantages 
of  common  architecture  and  major  interfaces  (Open  Systems  Joint  Task 
Force,  n.d.). 

The  OSJTF’s  role,  as  well  as  DoD’s,  is  a  top-down  leadership  role, 
providing  guidance  and  resources  and  coordinating  across  Services  and 
major  agencies  to  establish  policies.  Furthermore,  there  is  a  bottom-up 
mandate  that  requires  agencies  to  provide  the  daily  direction,  guidance, 
and  resources  required  to  implement  an  Open  Systems  environment. 


THE  TRANSFORMATION  LIFE  CYCLE:  GOING  FROM  CLOSED  TO  OPEN 

Along  with  establishing  an  Open  Systems  approach,  the  implementation 
of  a  Transformation  Life  Cycle  is  also  important  (Transformation  Life 
Cycle,  n.d.).  A  Transformation  Life  Cycle  is  an  approach  that  can  help 
the  government  and  corporate  entities  understand,  plan,  and  develop 
their  systems  to  meet  requisite  standards  of  interoperability.  Similarly, 
an  approach  of  this  type  can  help  the  government  achieve  an  alignment 
between  itself,  academia,  and  commercial  enterprise  business  practices. 
The  Transformation  Life  Cycle  will  also  allow  for  implementation  that 
crosswalks  technology  (i.e.,  legacy,  current,  and  future),  with  anticipated 
capabilities  leading  to  integrated  and  interoperable  systems  results. 

As  previously  described,  Open  Systems  is  not  in  and  of  itself  a  software 
product;  rather,  it  is  a  set  of  protocols,  standards,  and  a  hierarchical 
structure  from  which  software  and  hardware  are  built  to  ensure  that 
they  incorporate  and  pass  information  in  an  integrated  and  interoperable 
manner.  Additionally,  other  architectures,  standards,  and  protocols  are  in 
use  throughout  DoD;  some  of  these  are  described  below. 


OTHER  APPROACHES  ( HLA ,  DIS ,  AND  SOA) 

In  addition  to  Open  Systems,  other  architectures,  protocols,  and 
standards  have  been,  and  continue  to  be,  widely  used  by  DoD  and  industry. 
Some  of  these  include  DoD’s  High  Level  Architecture  (HLA),  Distributed 
Interactive  Simulation  (DIS),  and  Service-Oriented  Architecture  (SOA). 
These  have,  in  some  manner,  facilitated  the  integration  of  hardware, 
particularly  software,  bringing  the  constructive,  virtual,  and  live 
environments  together  into  a  coordinated  learning  environment  for 
training,  mission  planning,  and  mission  rehearsal. 

HLA,  developed  by  the  Defense  Modeling  and  Simulation  Office 
(DMSO),  was  designed  to  support  the  interoperability  of  various  DoD 
simulations.  HLA  was  approved  as  the  standard  technical  architecture 
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for  all  DoD  simulations  by  the  Under  Secretary  of  Defense  for  Acquisition 
and  Technology  in  September  1996,  and  was  later  approved  as  an  open 
standard  by  the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  in 
September  of  2000  (Defense  Modeling  and  Simulation  Office,  n.d.). 

Additionally,  HLA  has  been  an  essential  architecture,  supporting 
the  integration  of  disparate  constructive  simulations,  as  well  as  virtual 
simulators  and  live  systems.  As  previously  stated,  HLA  is  not  software; 
rather,  it  is  a  hierarchical  architecture  from  which  the  adherence  standards 
and  protocols  provide  the  integrating  glue,  connecting  the  Live,  Virtual, 
and  Constructive  (L-V-C)  system  environments. 

Furthermore,  a  principal  element  of  the  HLA  architecture  is  the 
Runtime  Infrastructure  (RTI).  RTI  coordinates  the  events  from  each 
system  environment,  facilitating  the  data  exchange  and  operations  and 
allowing  the  L-V-C  environment  to  work  in  a  federate  manner.  Essentially, 
the  simulation  systems  work  as  a  collection  of  simulators  that  share 
information  and  are  thus  changed  as  a  result  of  the  shared  events. 

DIS  is  also  a  useful  tool.  DIS  allows  multiple  users  to  work  interactively 
within  the  same  or  integrated  simulation  environment.  Examples  are  the 
distributed,  Internet-based  America’s  Army  game  or  a  federated  war 
game,  which  is  run  at  multiple  locations.  It  is  clear  that  a  federated  model 
using  HLA  can  also  be  DIS. 

DIS  is  built  on  Local  Area  Networks  or  Wide  Area  Networks  and 
depends  largely  on  the  robust  capability  of  the  network  to  handle  the  data 
and  information-exchange  transmission  rate.  A  well-designed  DIS  has  four 
basic  features  (Qin,  2002): 

•  Proper  interpretation  of  time 

•  Consideration  of  operation  transmission  delays 

•  Execution  of  operations  in  correct  order 

•  Allowance  of  real-time  response. 

DIS  is  an  important  aspect  of  a  simulation  environment.  Often,  bringing 
each  simulation  system  to  a  single  location,  establishing  connectivity,  and 
then  running  the  integrated  environment  are  not  feasible  or  cost-effective. 
Thus,  DIS  allows  simulations  to  interconnect  via  a  network  backbone. 

The  basic  underlying  concept  of  an  SOA  is  a  coupling  of  multiple 
services  within  an  architectural  structure.  These  services  are  called  upon 
by  customers  to  support  their  business  requirements.  The  Organization 
for  Advancement  of  Structured  Information  Standards  (OASIS)  defines 
SOA  as  “a  paradigm  for  organizing  and  utilizing  distributed  capabilities 
that  may  be  under  the  control  of  different  ownership  domains.  It  provides 
a  uniform  means  to  offer,  discover,  interact  with,  and  use  capabilities  to 
produce  desired  effects  consistent  with  measurable  preconditions  and 
expectations”  (OASIS,  n.d.). 
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An  important  aspect  of  SOA  is  that  it  provides  a  means  to  make 
services  interoperable  regardless  of  the  programming  language  used, 
location,  or  platform  of  a  simulation  or  model.  This  allows  organizations 
and  agencies  to  produce  their  software  on  an  appropriate  platform,  using 
architectural  guiding  principles  and  specified  standards  and  protocols, 
linking  these  resources  in  defined  and  spontaneous  ways  to  produce 
results  or  information.  Additionally,  this  promotes  reuse,  interoperability, 
and  growth  and  can  help  organizations  respond  to  ever-changing  and 
increased  demands  for  information  in  a  more  cost-effective  manner. 

Overall,  the  relationship  of  HLA,  DIS,  and  SOA  to  Open  Systems  is  that 
each  provides  a  step  in  the  right  direction  and  expands  across  systems  to 
incorporate  their  resident  capabilities  and  data  into  a  more  integrated  and 
interoperable  environment. 


ACHIEVING  GREAT  PERFORMANCE  THROUGH  OPEN  SYSTEMS 

Designing,  integrating,  and  evaluating  systems  and  System  of  Systems 
architectures  to  achieve  ever  greater  performance  and  capabilities  while 
controlling  development  and  sustainment  costs  present  perplexing 
problems  for  warfighters,  engineers,  analysts,  and  decision  makers. 
Furthermore,  these  individuals  continue  to  face  the  increasingly  difficult 
task  of  integrating  these  complex  simulations  and  live  systems  to  train,  plan, 
and  rehearse— a  strategy  designed  to  make  U.S.  warfighting  capabilities  a 
formidable,  unstoppable  force  against  any  adversary. 

The  preceding  priorities  must  be  accomplished  in  any  environment 
along  the  complete  spectrum  of  operations,  from  humanitarian 
assistance  to  full-scale,  force-on-force  operations.  Current  employed 
systems  comprise  legacy  equipment  and  current  technology,  but  must 
have  the  capacity  to  incorporate  future  technological  advances  as  they 
matriculate  through  development  and  are  incorporated  within  existing 
force  structures.  The  greater  introduction  of  space  and  cyber  assets  into 
our  Army  force  structure  will  exacerbate  even  further  the  requirement  for 
Open  Systems  that  effectively  and  efficiently  integrate  these  domains  into 
the  brigade  combat  team  (BCT).  Facilitating  this  critical  integration  and 
interoperability  requirement  necessitates  an  Open  Systems  approach. 


INTEROPERABILITY  AND  PHYSICAL  CONNECTIVITY 

As  a  basic  proposition,  interoperability  is  the  ability  to  work  together 
(Alberts  &  Hayes,  2003).  The  importance  of  interoperability  is  not  at  the 
connectivity  of  systems  within  an  L-V-C  environment;  rather,  its  importance 
is  manifested  at  the  information  and  cognitive  levels. 

Having  physical  connectivity  is  important.  However,  this  is  simply 
the  starting  point.  And  for  many,  this  is  often  where  the  discussion  stops 
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because  warfighters,  analysts,  engineers,  and  stakeholders  become 
trapped  in  the  details  of  bandwidth,  platforms,  cost,  etc.  This  social 
standard  is  transferable  to  physical  L-V-C  systems. 

Without  interoperability,  there  would  be  no  physical  connection  (i.e.,  a 
social  wave  between  systems),  which  opens  channels  to  pass  information 
for  sharing  and  allows  warfighters  to  understand  issues  and  situations,  and 
consequently  plan  and  implement  courses  of  action  designed  to  achieve 
success.  With  interoperability,  the  Army  Aviation  hunter-killer  team  is  able 
to  detach  from  each  other,  coordinate  and  communicate  via  their  physical 
connection,  and  share  information  and  understanding  to  hunt  and  kill  in 
a  distributed  manner.  Likewise,  the  Army’s  greater  and  greater  reliance 
on  commercial-off-the-shelf  (COTS)  technology  necessitates  the  need  for 
interoperability  standards  and  protocols  to  better  integrate  these  force 
multiplier  and  lifesaving  technologies  into  operational  environments. 


A  USEFUL  BLUEPRINT 

Open  Systems  standards  and  protocols  provide  a  blueprint  from  which  a 
purposeful  design  integrates  L-V-C  systems  and  facilitates  interoperability. 
The  true  goals  of  interoperability  are  shared  information  and  ultimately 
shared  understanding.  To  achieve  these  goals,  standards  and  protocols 
must  be  developed  within  the  social  structure  of  “humanness,”  which  will 
enable  the  achievement  of  interoperability. 

Without  a  common  language  or  the  ability  to  translate  different 
languages  so  that  entities  can  communicate,  sharing  information  and 
gaining  understanding  would  be  impossible.  For  example,  humans  have 
developed  a  standard  of  greeting,  which  consists  of  a  handshake  or  a  wave 
of  the  hand.  Both  signify  a  non-threatening  recognition  and  acceptance, 
and  they  open  the  opportunity  to  connect  and  communicate.  Likewise, 
Open  Systems  provide  a  similar  connection  between  entities. 


OTHER  ISSUES 

A  number  of  impediments  with  which  DoD  is  confronted  still  exist, 
which  are  counter  to  achieving  enterprise-wide  Open  Systems.  The  most 
prominent  is  cost.  Open  Systems  architectures  create  a  performance  and 
cost  escalation.  For  instance,  interfaces  within  components  that  are  strictly 
controlled  to  achieve  performance  gains  often  become  proprietary,  and 
thus  increase  the  cost  to  the  government.  Additionally,  the  development 
and  life-cycle  sustainment  costs  of  integrating  legacy  systems  with  future 
systems  across  DoD  are  prohibitive  when  addressed  in  total.  This  is  one  of 
the  reasons  that  DoD  leadership  is  tackling  this  requirement  incrementally. 

Closely  associated  with  cost  is  the  articulation  and  inclusion  of 
requirements  for  the  development  and  modification  of  systems  to 
facilitate  forward  and  backward  compatibility  of  Open  Systems  standards 
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FIGURE.  DoD  AND  CORPORATE  BUSINESS  PRIMARY  NEEDS  TO 
ACHIEVE  OPEN  SYSTEMS 
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and  protocols.  Without  the  vetted  and  approved  requirements  mandating 
the  acquisition  (i.e.,  government  and  commercial)  standards  that  must  be 
met  during  the  systems  development  phase  of  a  program,  Open  Systems 
will  be  ignored. 

However,  the  requirements  process  can  be  a  double-edged  sword. 
Though  it  clearly  mandates  that  a  program  manager  or  material  developer 
meet  the  requirements,  the  interpretation  of  requirements  can  lead  to  a 
cost  that  is  far  beyond  the  intent,  causing  a  scaling  back  of  the  requirement 
intent  and  ultimately  the  level  of  interoperability  across  DoD  L-V-C  systems. 
This  situation  starts  the  trade-space  analysis. 

Alternatively,  the  interpretation  of  requirements  can  lead  to  a  cost 
that  is  far  less  than  the  intent,  again  thwarting  the  goal  of  achieving  Open 
Systems.  What  is  needed  is  a  balance  (as  depicted  in  the  Figure)  between 
the  DoD’s  needs  and  corporate  business  imperatives,  and  also  the  ability 
to  deliver  Open  Systems. 

As  demonstrated,  DoD  must  develop  an  environment  that  is  designed 
to  encourage  technology  development  and  competition  within  an  Open 
Systems  framework.  This  will  require  strong,  earnest  leadership  and 
governance.  This  leadership  and  governance  must  be  top-down  and  must 
have  consistency  over  time,  as  DoD  is  a  customer  with  high  expectations. 


Open  Systems  Solutions 

The  governance  of  the  Open  Systems  approach  must  be  continually 
reviewed  and  updated  to  provide  a  success-driven  environment.  The  Army 
recognizes  the  importance  of  governance  and  thereby  creates  a  means 
to  implement  Open  Systems  by  socializing,  formalizing,  resourcing,  and 
implementing  processes  to  transition  from  closed  to  Open  Systems. 
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The  Army  also  evaluates  systems  throughout  the  acquisition  process 
to  ensure  that  they  meet  Open  Systems  standards.  The  governance  of 
this  campaign  should  adopt  the  Open  Systems  framework  and  should  be 
the  decision-making,  regulatory,  and  enforcement  structure  to  ensure 
that  requirements,  standards,  and  protocols  are  met.  For  example,  new 
initiatives  like  a  new  architecture  require  that  the  agency  either  fund  for 
the  mandate  or  nurture  a  community  of  interest  that  will  provide  input  and 
see  benefit  to  incorporate  such  models. 

Corporate  entities  that  support  the  DoD  are  not  expected  to  act  as 
patriots.  Rather,  they  should  manage  the  customers'  expectations  and 
should  work  with  customers  to  craft  appropriate  strategies  to  achieve 
Open  Systems.  They  should  also  recognize  that  cost  is  a  significant  factor, 
and  that  incremental  steps  must  be  funded. 

These  incremental  steps  should  be  framed  within  an  overall,  larger 
encompassing  campaign,  focused  on  a  sector  of  the  defense  industrial 
complex.  DoD  and  corporate  partners  must  come  to  terms  with  the 
balance  of  client  needs  and  funding  realities  to  profit,  proprietary  rights, 
and  intellectual  capital.  The  solutions  are  both  political  and  technical. 

At  the  same  time,  bottom-up  champions  who  are  dedicated  to 
achieving  a  comprehensive,  integrated  L-V-C  Open  Systems  environment 
are  needed.  Additionally,  these  implementers  need  to  develop  proof-of- 
principle  facilities  that  work  collaboratively  with  the  materiel  developers 
to  test  and  validate  that  the  systems  meet  Open  Systems  standards 
and  protocols,  and  to  be  certain  that  they  are  truly  integrated  and 
interoperable.  These  champions  must  also  be  funded  and  empowered 
to  make  decisions  within  the  established  governance  framework,  and 
must  make  appropriate  changes  and  take  those  changes  to  the  executive 
governance  body  for  decision. 

Overall,  implementing  and  maintaining  an  Open  Systems  approach  is 
an  involved  yet  essential  requirement.  Due  to  the  nation’s  current  state 
and  the  increasing  demands  placed  upon  the  Army,  new  and  innovative 
systems  of  technology  are  consistently  needed  and  required.  Certainly 
no  system  is  without  concerns  or  impediments,  and  the  Open  Systems 
approach  is  no  exception.  However,  if  problems  are  addressed  as  needed 
and  if  proper  governance  is  in  place,  Open  Systems  can  be  achieved. 
The  result  of  an  Open  Systems  architecture  is  the  development  of  an 
environment  that  provides  the  training,  mission  rehearsal,  and  warfighter 
planning  that  support  our  Army— all  of  which  will  sharpen  our  warfighting 
edge  and  ensure  our  dominance  across  the  full  spectrum  of  operations. 
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APPENDIX 

List  of  Acronyms 
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Live,  Virtual,  and  Constructive 
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Standards 
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Runtime  Infrastructure 
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A  TIME  STUDY  OF 
SCIENTISTS  &  ENGINEERS 
(S&Es)  IN  THE  AIR 
VEHICLES  DIRECTORATE 

i  Jo  Ann  McCabe  and  Col  John  Wissler,  USAF 

The  Air  Vehicles  Directorate  of  the  Air  Force  Research  Labo¬ 
ratory,  concerned  that  its  scientists  and  engineers  (S&Es) 
were  spending  more  time  on  nontechnical  duties  than  on 
technical  duties,  developed  a  Web-based  means  of  gath¬ 
ering  data  on  this  issue.  After  almost  27,000  hours,  recorded 
data  showed  approximately  19  of  40  hours  in  an  average 
week  were  spent  on  technical  taskings.  This  led  the  direc¬ 
torate  to  examine  various  ways  of  increasing  the  share  of 
technical  time  productivity  reported  by  its  S&Es.  This  article 
highlights  the  authors’  data  gathering  results  and  offers 
insights  on  increasing  the  technical  and  value-added  time  of 
S&Es,  thereby  resulting  in  increased  productivity  for  AFRL— 
an  important  Air  Force  resource. 


Keywords:  Time  Study  of  Scientists  and  Engineers, 
Air  Force  Research  Laboratory  (AFRL)  Research, 
Air  Force  Research  Laboratory  Time  Study, 

How  Scientists  and  Engineers  Spend  Their  Time, 
Technology-Focused  Research  Organizations, 

Value  and  Non-Value  Added  Work  in  a  Government 
Laboratory,  Research  Day 
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The  Air  Vehicles  Directorate,  located  at  Wright-Patterson  Air  Force 
Base,  is  one  of  the  10  technology-focused  research  organizations  in  the  Air 
Force  Research  Laboratory  (AFRL).  We  employ  approximately  600  people, 
close  to  one-third  of  whom  are  government  scientists  and  engineers 
(S&Es),  and  develop  advanced  flight  vehicle  technologies  in  the  areas  of 
aerodynamics,  control  of  flight  vehicles,  and  structural  sciences.  Our  work 
is  analytical,  computational,  and  experimental,  accomplished  in  both  in- 
house  and  external  facilities,  and  involving  programs  with  academia  and 
industry.  Although  our  natural  focus  is  on  the  long-term  future,  we  also 
solve  shorter-term,  more  urgent  problems  for  the  Air  Force. 

The  Air  Vehicles  Directorate  and  its  predecessor  organizations  have  a 
long  history,  and  our  technologies  can  be  found  in  practically  every  major 
weapon  system  in  today's  U.S.  Air  Force  inventory.  In  response  to  budget 
cuts,  drives  for  efficiency,  and  numerous  reforms,  the  workforce  in  the 
Air  Vehicles  Directorate  has  declined  16  percent  in  the  last  decade  (C. 
Remillard,  personal  communication,  April  10,  2008).  Many  of  these  cuts 
resulted  in  the  reduction  of  non-technical  personnel,  thus  often  leaving 
some  nontechnical  taskings  to  our  S&Es. 

Concern  regarding  the  DoD’s  acquisition  workforce  capability  and 
competency  is  increasing  (Taubman,  2008).  At  the  organizational  level, 
anecdotal  evidence  supports  the  view  that  our  technical  workforce  does 
not  feel  it  accomplishes  enough  technical  work.  This  view  is  a  frequently 
cited  frustration  that  has  been  noted  in  recent  cultural  surveys  and 
exit  interviews,  and  discussed  during  formal  and  informal  mentoring 
sessions.  Concerns  have  been  raised  at  director’s  calls,  overheard  in  the 
hallways,  and  documented  by  supervisors  during  feedback  sessions. 
These  concerns  have  continued  despite  initiatives  such  as  Air  Force 
Smart  Operations  for  the  21st  Century  (AFSO-21)  and  business  process 
reengineering,  which  are  directed  at  reducing  non-value-added  work, 
increasing  our  S&Es’  bench  time,  and  making  the  most  of  AFRL’s  technical 
talent.  AFSO-21,  introduced  by  former  Secretary  of  the  Air  Force  Michael 
Wynne  in  his  Secretary  of  the  Air  Force  Letters  to  Airmen  in  December 
2005  and  March  2006,  described  it  as  “a  dedicated  effort  to  maximize 
value  and  minimize  waste  in  our  operations”  (Wynne,  2005,  p.  1;  Wynne, 
2006,  p.  1)  and  "AFSO-21  is  about  working  smarter  to  deliver  warfighting 
capabilities”  (Fludson,  2006,  p.  5). 

According  to  Lt  Gen  John  L.  “Jack”  Fludson,  USAF,  commander  of  the 
Aeronautical  Systems  Center  in  a  Commentary  dated  September  15,  2006, 
“Our  mission  of  providing  warfighting  capabilities  has  never  been  more 
important,  and  we  must  continually  find  ways  to  do  this  more  efficiently 
and  effectively,  despite  manpower  and  budgetary  constraints.  AFSO-21 
will  help  us  do  that”  (p.  1).  According  to  Jenkins  (2009),  there  is  a  need 
for  having  a  framework  for  workplace  satisfaction  and  organizational 
commitment.  Jenkins  states  that  this  framework,  “integrates  McGregor's 
Theories  X  and  Y,  Maslow’s  hierarchy  of  needs,  and  Meyer  and  Allen’s 
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three-part  organizational  commitment  theory”  (pp.  21-23).  Jenkins  lists 
factors  related  to  workplace  satisfaction:  pay  and  benefits;  growth  and 
development  opportunities;  relevance  or  meaning  of  job;  supervision;  and 
feelings  towards  co-workers.  What  is  not  listed  as  relevant  is  the  fact  that 
many  of  our  S&Es  simply  want  to  do  what  they  do  best:  engineering  and 
science.  A  key  part  of  that  is  assessing  how  much  engineering  and  science 
they  are  actually  doing. 

In  general,  the  feedback  from  our  workforce  is  that  people  want  to 
concentrate  on  their  research  and  technical  work,  i.e.,  the  intellectual  work 
associated  with  their  core  duties,  not  the  excessive  program  management 
and  administrative  responsibilities  required  to  support  that  work.  So  the 
question  was  asked:  How  do  S&Es  in  the  Air  Vehicles  Directorate  spend 
their  time? 


The  Approach 

To  answer  that  question,  we  first  needed  a  way  to  gather  data  about 
how  our  S&Es  spend  their  time.  One  possible  approach  was  to  use  the 
organization’s  existing  timekeeping  system.  However,  this  system  only 
tracks  the  amount  of  time  our  workforce  charges  to  their  projects,  not  the 
type  of  task  performed  in  support  of  those  projects.  Another  challenge  was 
working  with  a  relatively  small  population.  Statistically,  in  order  to  attain  a 
95  percent  confidence  interval,  we  would  have  needed  122  respondents. 
Given  not  everyone  would  take  the  time  to  submit  data,  we  instead  chose 
to  conduct  a  census  and  invite  all  our  S&Es  to  participate,  after  which  we 
would  accept  whatever  we  could  get.  Admittedly,  we  were  less  concerned 
about  confidence  intervals  and  absolute  statistical  rigor  than  we  were 
about  identifying  issues  and  trends  and  taking  steps  to  address  them.  We 
would  then  use  the  information  to  help  us  increase  the  time  each  S&E 
spent  in  technical  activities  and  increase  the  value-added  aspects  of  the 
S&Es’  work. 

We  developed  an  intranet  Web  site  that  would  enable  us  to  collect: 

•  Number  of  hours  worked  in  various  activity/category  types 

•  Whether  the  hours  worked  were  considered  by  S&Es  to  be 
value-  or  non-value-added 

•  Comments,  especially  if  the  S&Es  reported  the  activity  to  be 
of  no  value. 

To  encourage  participation,  we  ensured  the  anonymity  of  each 
respondent  providing  the  information  and  designed  the  site  so  that  it  took 
less  than  5  minutes  each  day  to  complete. 
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FIGURE  1.  INTRANET  WEB  SITE  FOR  RECORDING  TIME  STUDY 
INFORMATION 
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To  submit  hours  simply  select  a  day  from 
the  calendar  above,  enter  the  number  of 
hours  spent  working  in  a  particular  time 
area,  select  whether  that  time  spent  added 
value,  and  enter  any  comments  that  you 
might  have  (optional). 
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The  Web  site  is  shown  in  Figure  1.  To  the  left  is  a  calendar  showing  the 
date  and  the  day  for  which  data  was  being  entered.  The  right  hand  side 
contains  a  number  of  items  to  be  filled  out,  such  as  the  number  of  hours 
worked  on  a  particular  activity,  the  activity  performed,  a  value  indication, 
and  a  text  entry  box  for  any  comments  the  submitter  cared  to  make.  At  the 
bottom  of  the  site  is  a  table  (Hours  Entered)  that  displayed  the  data  as  the 
respondents  entered  it.  Once  respondents  logged  into  the  Web  site,  they 
simply  entered  the  data  regarding  their  activities  for  that  day.  The  Web 
site  was  designed  so  that  if  they  missed  a  day,  respondents  could  click  on 
the  missed  day  and  enter  the  data.  Only  activities  in  the  standard  workday 
(nominally  a  40-hour  federal  work  week)  were  to  be  logged. 

Prior  to  launching  the  2-month  Time  Study,  we  ran  a  1-week  beta 
test  that  resulted  in  the  refined  categories  shown  in  the  Table,  which 
also  shows  the  four  major  categories  into  which  the  data  were  binned: 
Technical,  Program  Management,  Administration,  and  Miscellaneous.  Note 
that  Program  Management  consists  of  only  one  subcategory  that  covers 
administratively  oriented  tasks  associated  with  program  management, 
such  as  putting  program  budgets  into  the  management  information 
systems.  We  characterized  the  intellectual  tasks  associated  with  program 
management  as  technical  (e.g.,  technical  planning). 

Then,  in  July  2007,  we  had  an  all-hands  meeting  with  our  S&Es,  during 
which  we  provided  them  with  an  overview  of  the  Time  Study,  including  a 
demonstration  of  the  Web  tool.  Additionally,  we  asked  the  S&Es  for  their 
support  and  stressed  that  individual  identities  would  be  masked. 
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The  data  collection  period  ran  for  2  months  (July  and  August  2007). 
To  help  our  census  respondents  remember  to  fill  out  the  questionnaire, 
our  Web  Team  issued  periodic  pop-up  reminders  on  the  network;  we 
also  sent  them  periodic  e-mail  reminders.  Additionally,  the  Air  Vehicles 
director  would  send  periodic  e-mails  asking  people  to  participate.  Not 
unexpectedly,  these  resulted  in  increased  participation. 


Results 

In  total,  over  the  2-month  period,  approximately  27,000  hours  of  time 
data  were  logged  by  the  S&Es  in  the  Air  Vehicles  Directorate.  To  make 
the  data  more  relevant  to  the  average  S&E’s  activities,  we  normalized  the 
data  into  the  standard  40-hour  work  week,  thus  creating  the  picture  of  an 
average  S&E. 

Figure  2  shows  the  top-level  results.  Technical  activities  comprised 
slightly  over  19  hours  per  week  for  our  average  S&E,  and  Program 
Management  accounted  for  another  4  hours.  Administrative  and 
Miscellaneous  activities  accounted  for  the  remaining  17  hours.  Thus,  it 
appears  that  the  majority  of  our  average  S&E’s  time  is  spent  on  either 
Technical  or  Program  Management,  although  only  by  a  slim  majority. 

Figure  3  shows  the  same  data,  now  accounting  for  the  value-added 
versus  non-value-added  time.  It  shows  that  our  S&Es  reported  non¬ 
value-added  activities  in  all  categories.  However,  nearly  one-third  of 

FIGURE  2.  TOP-LEVEL  RESULTS— SCALED  TO  A  40-HOUR  WORK 
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FIGURE  3.  TOP-LEVEL  RESULTS-VALUE  ADDED  VS.  NON-VALUE 
ADDED 
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FIGURE  4.  COMPARISON  OF  VALUE-ADDED  TIME-MILITARY  S&Es 
VS.  CIVILIAN  S&Es 
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FIGURE  5.  COMPARISON  OF  NON-VALUE-ADDED  TIME-MILITARY 
S&Es  VS.  CIVILIAN  S&Es 
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the  administrative  activities  accounted  for  were  viewed  as  non-value- 
added— the  largest  percentage  among  all  four  categories.  The  program 
management  category  showed  the  lowest  absolute  amount  of  non-value- 
added  activities,  but  on  a  percentage  basis  within  a  category,  our  S&Es 
felt  that  technical  activities  had  the  largest  value  (as  one  would  expect). 

Figure  4  shows  how  our  military  S&Es,  mostly  junior  officers  (second 
lieutenants  through  captains),  compare  to  our  civilian  S&Es,  who  fall 
within  a  broad  spectrum  of  grades,  from  GS-11  to  GS-14  equivalent.  It 
shows  that  civilian  S&Es  reported  a  slightly  greater  share  of  value-added 
hours  for  Technical  and  Program  Management  activities,  while  military 
S&Es  reported  a  slightly  higher  value-added  share  for  Administrative  and 
Miscellaneous  tasks. 

Figure  5  shows  the  same  data  for  non-value-added  activities.  It  shows 
that  the  military  perception  of  non-value-added  activities  is  slightly  higher 
overall,  with  the  biggest  difference  between  civilian  and  military  being  in 
the  miscellaneous  category. 


Discussion 

Surprisingly,  the  results  countered  to  a  certain  extent  the  anecdotal 
evidence  that  our  S&Es  spent  little  or  no  time  on  technical  activities, 
painting  a  good  news/bad  news  picture.  Clearly,  close  to  one-half  of  a 
40-hour  work  week  was  spent  on  technical  work  (good  news;  after  all, 
our  S&Es  perceived  they  did  little  or  no  technical  work!).  Flowever,  the  bad 
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news  was  that  technical  work  comprised  only  19  hours  a  week.  It  indicated 
we  can  use  our  employees’  time  more  wisely. 

Although  the  non-value-added  component  was  lower  than  we 
originally  expected,  it  nonetheless  comprised  almost  a  full  day  out  of  a 
5-day  week.  Again,  it  was  a  good  news/bad  news  story.  The  good  news 
was  that  it  was  only  a  day  and  not  2  or  3  days.  The  bad  news  was  that  it 
was  a  day  and  not  a  half  day  or  less.  We  assume  it  is  impossible  to  drive  it 
to  zero  (after  all,  we  are  part  of  the  federal  government!).  But,  we  should 
be  able  to  drive  it  to  less  than  a  day.  We  recognize  that  different  people 
in  different  jobs  have  different  perceptions  of  value;  most  of  our  S&Es 
view  the  major  share  of  the  administrative  work  they  do  as  having  little 
or  no  value. 

One  area  of  concern  is  the  data  that  shows  our  military  junior  officers 
doing  more  administrative  and  miscellaneous  work  as  compared  to  their 
civilian  counterparts.  To  a  certain  extent,  this  makes  sense;  many  of  our 
additional  duties  tend  to  be  administrative  in  nature  and  tend  to  fall  into  the 
laps  of  our  officers.  However,  given  that  we  are  theoretically  preparing  our 
young  officers  for  increased  responsibility,  one  has  to  ask  whether  placing 
the  administrative  and  miscellaneous  burden  on  them  is  the  best  use  of 
their  talents  and  the  best  way  to  develop  them.  Certainly,  their  academic 
background  and  officer  training  could  be  better  utilized,  especially  given 
the  fact  that  our  S&E  workforce  has  declined  in  number. 

Before  we  took  on  the  challenge  of  reducing  the  number  of  non-value- 
added  tasks  in  an  S&E’s  work  week,  we  checked  out  our  concerns  with 
Air  Force  pilots  and  leaders  from  industry.  We  asked  several  Air  Force 
rated  officers:  Would  it  be  acceptable  if  line  pilots  spent  only  half  their 
time  thinking  about,  preparing  for,  or  actually  flying?  The  consensus  was 
that  it  would  not  be  acceptable.  The  obvious  question  for  the  Air  Force 
is,  if  spending  less  than  half  one’s  time  on  core  duties  is  unacceptable  for 
the  flying  community,  then  why  should  it  be  acceptable  for  the  technical 
community? 

We  then  asked  several  of  our  industry  counterparts  how  their 
engineers  spent  their  time.  Their  responses  left  us  with  the  sense  that 
although  they  probably  spent  more  than  half  their  time  on  technical  work, 
a  large  portion  of  their  time  was  also  spent  on  marketing  and  business 
development.  Our  industry  colleagues  also  said  that  most  companies 
try  to  get  the  most  out  of  their  highly  trained  and  well-paid  technical 
workforce  and  do  this  partly  by  offloading  as  much  administrative  work 
as  they  can  to  nontechnical  personnel. 

The  next  question  is:  Now  what?  We  want  to  make  the  most  of  the 
technical  talent  we  have  in  the  Air  Vehicles  Directorate.  We  want  to  look 
at  non-value-added  efforts,  and  we  want  to  increase  bench  time  for  S&Es 
because  we  believe  it  represents  better  value  for  the  American  taxpayer; 
and  it  is  clearly  a  morale,  motivation,  and  recruiting  issue. 
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The  directorate’s  leadership  identified  three  possible  initiatives  we 
anticipate  will  increase  the  bench  time  of  our  S&Es.  The  first  initiative, 
The  First  Three  Years  Program,  is  an  Air  Force  Research  Laboratory¬ 
wide  program.  The  second  initiative  is  the  hiring  of  technical  business 
specialists  to  assist  the  S&Es,  and  the  third  initiative  is  the  implementation 
of  Research/Focus  Day. 


THE  FIRST  THREE  YEARS  PROGRAM 

In  a  move  to  ensure  every  newly  hired  federal  civilian  service  S&E  and 
lieutenant  can  become  a  successful  technology  leader  (i.e.,  researcher, 
program  manager,  or  supervisor),  AFRL  implemented  The  First  Three  Years 
Program.  The  program’s  goal  is  to  allow  young  S&Es  to  become  comfortable 
with  the  laboratory  environment  from  a  bench-level  perspective  before 
taking  on  more  complex  program  management  functions.  The  program 
requires  supervisors  to  assign  technical  mentors  to  oversee  the  technical 
training  of  our  S&Es  during  their  first  three  years  of  employment  (Fast, 
2009).  Its  basis  is  the  belief  that  the  primary  function  of  bench-level  military 
and  civilian  S&Es  is  to  perform  mission-focused  science  and  technology 
work  for  their  first  three  years,  as  well  as  reviews  of  management  literature 
concerned  with  the  career  management  of  scientific  personnel  (Clarke, 
1996;  Farris  &  Cordero,  2002).  The  mentors  oversee  the  technical  training 
of  our  new  S&Es,  with  both  on-the-job  training  (OJT)  and  formal  training. 
A  formal  Individual  Development  Plan  (IDP),  required  for  each  employee 
within  the  first  60  to  90  days  of  assignment  and  outlining  both  formal 
and  OJT  assignments,  helps  the  employee  and  the  supervisor  map  out  a 
strategy  to  help  new  S&Es  contribute  quickly  and  effectively. 


TECHNICAL  BUSINESS  SPECIALISTS 

Based  on  this  study’s  results,  we  determined  that  decreasing 
administrative  workload  on  S&Es  is  clearly  a  necessity.  Hiring  additional 
government  S&Es  to  perform  this  duty,  however,  is  not  a  practical  option 
because  the  Air  Force  places  limits  on  manpower  authorizations.  This 
solution  is  also  completely  counter  to  increasing  the  technical  content  of 
what  our  S&Es  do. 

A  different  option  is  to  hire  a  small  number  of  government  business 
specialists  to  perform  basic  program  management  tasks.  Specifically,  we 
decided  to  hire  six  technical  business  specialists,  two  of  which  would  be 
assigned  to  each  of  the  three  technical  divisions  to  become  part  of  the 
program  manager  support  team.  S&Es  will  remain  assigned  as  program 
managers,  and  the  new  specialists  will  augment  any  personnel  currently 
doing  similar  duties  within  the  division.  The  administrative  burden  that  the 
technical  business  specialists  remove  from  the  S&Es  will  free  a  significant 
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portion  of  the  S&Es’  work  week,  allowing  them  to  focus  on  core  technical 
activities,  reduce  the  program  management  workload,  and  increase  the 
time  spent  performing  research.  Our  S&Es  have  reacted  positively  to  this 
new  practice,  which  has  acted  as  an  unexpected  motivator.  The  S&Es 
accurately  interpreted  the  proposed  practice  that  management  values 
their  research  and  development  time.  As  pointed  out  by  Ralph  Katz  (1997), 
if  technical  employees  believe  their  work  is  challenging  and  innovative, 
and  if  they  have  the  freedom  to  do  what  they  do  best,  they  will  work  to 
meet  the  demands  the  research  calls  for. 

A  potential  argument  against  filling  these  positions  is  that  they 
increase  the  number  of  administrative  personnel  relative  to  the  S&Es, 
thereby  reducing  the  "tooth-to-tail”  ratio.  However,  we  would  submit  that 
tooth-to-tail  is  more  than  just  a  body  count.  It  is  also  the  kind  of  functions 
that  people  in  those  positions  actually  perform.  Having  an  expensive  and 
technically  trained  S&E  perform  functions  that  could  easily  be  done  by 
a  nontechnical  and  less  expensive  business  specialist  in  effect  makes 
the  tooth-to-tail  ratio  worse,  not  better.  This  is  especially  true  if  several 
S&Es  perform  work  on  a  part-time  basis,  thus  doing  that  work  inefficiently 
while  the  per  hour  cost  is  higher.  Having  the  technical  business  specialists 
perform  some  of  the  critical  nontechnical  functions  will  increase  the 
efficiency  with  which  those  functions  are  accomplished,  enable  the  S&Es 
to  spend  more  time  on  the  technical  intellectual  content  of  what  they  do, 
and  also  increase  morale,  recruiting,  and  retention. 


RESEARCH/FOCUS  DAY 

Probably  the  most  controversial  idea  we  implemented  may  prove  to 
be  the  most  beneficial.  The  directorate  has  designated  every  Thursday 
as  a  day  in  which  each  employee  is  asked  to  spend  their  time  working 
only  on  their  core  function,  whether  it  be  technical  or  nontechnical.  One 
of  our  employees  said  it  best  when  he  responded  to  the  question:  What 
should  we  be  working  on?  His  response  was:  “On  Research  Day,  do  what 
you  would  do  if  you  had  to  come  in  on  a  Saturday  to  get  done  what  you 
couldn’t  get  done  during  the  week.  That’s  what  you  should  be  working  on” 
(T.  C.  Hummel,  personal  communication,  August  30,  2007). 

To  help  personnel  concentrate  on  these  core  tasks,  the  directorate 
refrains  from  issuing  new  administrative  taskings  on  Thursdays,  and 
requests  that  non-core  training  and  meetings  be  deferred  to  another  day. 
Employees  are  also  encouraged  to  minimize  e-mails.  Directorate  leaders 
(branch  chiefs  and  above)  are  expected  to  walk  around  and  ensure  that 
personnel  are  following  the  rules  of  Research/Focus  Day.  Surprisingly,  the 
hardest  part  of  implementing  it  has  been  getting  people  to  think  about 
their  core  duties  and  then  have  the  discipline  to  focus  on  them.  This  may 
be  a  symptom  of  the  fragmented  nature  in  which  we  have  operated.  In  any 
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case,  we  are  continuing  to  emphasize  the  use  of  Thursdays  and  the  need 
to  use  them  to  concentrate,  not  fragment. 


Conclusions 

Clearly,  the  Time  Study  was  a  first  attempt  to  define  and  break  down 
how  Air  Vehicles  Directorate  S&Es  spend  their  time.  We  are  considering 
repeating  the  Time  Study  in  fall  2009.  We  will  compare  the  results  of  the 
original  study  and  look  at  other  assessments  directed  at  our  workplace 
environment. 

As  we  continue  to  develop  our  personnel  and  provide  them  with 
meaningful  work,  increasing  the  time  spent  by  our  military  and  civilian 
technical  personnel  on  technical  tasks  must  remain  a  priority.  Increasing 
the  amount  of  time  spent  on  technical  tasks  represents  a  best-value 
proposition  for  the  Air  Force  because  it  maximizes  the  payoff  associated 
with  hiring  S&Es.  Additionally,  the  working  environment  is  also  improved 
because  through  the  conduct  of  this  Time  Study  and  responsive  follow-up 
actions,  our  workforce  understands  that  we  listen  to  them,  we  hear  them, 
and  we  are  taking  their  best  interests  to  heart. 
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TECHNOLOGY  CORNER: 

THE  REAL  CHALLENGE 
OF  WEB  2.0 

f  Mark  Oehlert 

The  hardest  part  about  implementing  “Web  2.0”  or  “Social 
Media”  within  the  defense  acquisition  workforce  is  not 
acquiring  new  technology,  successful  change  manage¬ 
ment,  or  organizational  design.  The  most  difficult  challenges 
confronting  users  of  this  new  technology  are  not  monetary, 
functionality,  or  even  integration;  rather,  the  most  difficult 
challenges  are  difficult  questions  about  how  the  workforce 
regards  the  dynamics  of  fear,  control,  and  trust  within  their 
own  organizations.  Can  these  very  human  questions  be 
answered  in  a  manner  that  most  fully  exploits  the  capabilities 
that  are  now  open  to  the  acquisition  workforce?  In  this  article, 
the  author  seeks  to  answer  that  question  and  provide  insight 
and  close  examination  of  this  new  21st  century  phenomenon 
called  Web  2.0. 


Keywords:  Web  2.0,  Social  Media,  Culture,  Change 
Management,  Organizational  Design 
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Instead  of  pouring  knowledge  into  people’s  heads,  we  need  to  help 
them  grind  a  new  set  of  glasses  so  they  can  see  the  world  in  a  new  way. 
That  involves  challenging  the  implicit  assumptions  that  have  shaped 
the  way  people  have  historically  looked  at  things. 

John  Seely  Brown 

The  quote  that  begins  this  article  speaks  to  humanity’s  common  need 
to  avoid  assumptions  of  the  past  in  order  to  move  forward  (Brown,  2003). 
At  no  time  in  history  have  assumptions  of  the  past  been  left  so  far  behind 
in  the  dust  as  in  the  past  quarter  century.  The  Information  Age  has  ushered 
in  the  phenomenon  of  the  Internet— a  global  cultural  gift  to  mankind  that, 
in  recent  years,  has  spawned  its  own  technological  child:  “Web  2.0”  or 
“Social  Media.”  This  article  briefly  examines  the  profound  effect  of  social 
media  on  the  way  we  work  and  learn. 

Working  under  a  research  grant  approximately  10  years  ago,  this 
author  interviewed  a  number  of  managers  who  had  been  in  charge 
of  implementing  Learning  Management  Systems  (LMS)  within  their 
organizations.  One  question  posed  asked  them  to  name  the  largest  single 
hurdle  to  the  successful  installation  and  integration  of  the  LMS.  Was  there 
sufficient  funding?  Yes.  Staffing?  Yes.  Were  there  hiccups  in  technical 
terms?  Sure,  but  nothing  catastrophic.  What  then  was  this  single  greatest 
hurdle  to  success?  In  every  organization,  the  answer  was  insufficient 
organizational  design  and  change  management.  So  then  the  question  was 
posed  to  the  LMS  vendors:  Do  you  provide  any  organizational  design  or 
change  management  services  with  your  products?  None  did.  The  history 
of  LMS  is  now  replete  with  stories  of  companies  on  their  third,  fourth,  and 
fifth  LMS  installs.  Herein  lies  the  lesson  of  history  and  the  real  challenge 
of  Web  2.0. 

Sometimes,  it  feels  like  the  challenge  of  2.0  or  social  media  is  one 
of  keeping  up  with  technology.  Seemingly,  a  new  tool  is  created  and 
launched  in  a  matter  of  seconds  versus  the  pace  of  2.0’s  predecessor 
technology.  Right  now,  around  100,000  apps  are  available  for  the  iPhone 
alone  (Farrell,  2009).  More  and  more,  the  real  challenge  appears  to  be 
one  of  security.  This  author  was  fortunate  enough  to  serve  on  the  working 
group  that  helped,  in  some  small  part,  to  craft  the  current  (as  of  October 
2009)  draft  of  a  DoD-wide  policy  for  social  media  usage  that  is  currently 
being  coordinated.  A  quick  review  of  articles  on  this  topic  (Bezier,  2009) 
and  the  actual  comments  coming  back  from  the  field  pinpoint  a  level 
of  concern  over  the  exposure  of  systems  or  classified  information.  This 
concern,  however,  as  interpreted  by  the  author  from  both  the  articles 
reviewed  and  comments  from  the  field,  clearly  translates  into  an  element 
of  distinct  anxiety. 

The  challenge  that  the  defense  acquisition  workforce  and  all  of  the 
Department  of  Defense  faces  in  implementing  the  benefits  of  social  media 
lies  in  the  ability  to  confront  the  Three  Horsemen  of  Social  Media:  Fear, 
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Control,  and  Trust  (Hinchcliffe,  2009).  How  many  times,  when  something 
like  social  media  is  brought  up  (and  it  must  have  happened  when  e-mail 
was  dawning),  do  we  hear  objections  such  as,  What  if  people  say  the  wrong 
things?  What  if  people  say  secret  things?  What  if  people  say  bad  things? 
All  of  these  statements  indicate  some  level  of  fear  of  the  vulnerabilities 
that  these  new  technologies  would  launch  into  the  workplace.  The  only 
problem?  They’re  wrong— and  they  ignore  the  tangible  and  intangible 
costs  of  a  missed  opportunity. 

The  reason  these  objections  are  a  collective  red  herring  is  that 
social  media  actually  do  not  create  any  of  these  as  new  vulnerabilities.  If 
employees  have  e-mail  and  phones  or  even  access  to  copy  machines,  the 
ability  and  vulnerability  for  them  to  create  mass  havoc  already  exists. 

The  First  Horseman:  Fear 

Consider  the  story  of  Pandora’s  box  (Wikipedia,  n.d.).  Pandora  is  given 
a  box  and  told  not  to  open  it.  Her  curiosity  overcomes  her  though,  and  she 
opens  the  box  and  releases  all  the  ills  of  the  world.  The  end  of  the  story, 
however,  is  often  left  out.  Pandora  does  manage  to  shut  the  box  again, 
trapping  only  hope  inside.  This  is  exactly  what  the  fear  of  social  media 
is  doing.  By  not  going  forward,  albeit  prudently  and  thoughtfully,  the 
acquisition  workforce  is  not  managing  to  prevent  any  new  vulnerabilities. 
Rather,  they  are  simply  managing  to  keep  out  the  very  capabilities— 
increased  sharing  of  knowledge  and  increased  collaboration— that 
could  actually  mitigate  some  existing  vulnerabilities.  Even  the  defense 
intelligence  community  is  recognizing  and  embracing  that  dynamic. 

The  Second  Horseman:  Control 

The  second  anxiety-causing  dynamic  relates  to  control.  The  defense 
acquisition  workforce  and  its  managers  have  always  thought  (and  taught) 
that  tighter  and  tighter  control  would  help  everyone  "stay  on  message’’; 
social  media  destroys  that  paradigm.  What  social  media  teaches  is  that 
to  control  or  shape  the  message,  one  actually  has  to  participate  in  the 
discussion. 

One  of  the  best  examples  of  this  is  a  blog  written  by  Bob  Lutz,  the 
vice  chairman  for  General  Motors.  Lutz  started  the  blog  about  GM  cars 
called  the  FastLane  Blog  (Lutz,  2009).  When  it  debuted,  readers  seriously 
doubted  if  Lutz  was  really  writing  it.  He  eventually  confirmed  it  was  really 
him,  and  managed  to  start  an  authentic  conversation  with  GM  customers. 
Regardless  of  what  happened  to  the  company  from  a  financial  standpoint, 
Lutz  realized  that  press  releases  just  did  not  convince  anyone  of  anything. 
Therefore,  to  shape  the  conversation  about  GM  cars,  he  gave  up  the 
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mythical  control  of  only  releasing  “approved”  content  and  acting  like 
people  were  not  talking  about  GM  cars  anyway— and  simply  jumped  into 
the  thick  of  things. 

The  current  Chairman  of  the  Joint  Chiefs  of  Staff  is  on  Facebook 
and  Twitter  (Facebook,  2009);  and  the  Chief  Information  Officer  of  the 
Department  of  the  Navy  blogs  (CHINFO,  2009).  They  do  these  things  for 
several  reasons,  but  one  is  to  shape  the  conversation  by  being  part  of  it. 


The  Third  Horseman:  Trust 

The  final  and  third  horseman  is  Trust.  This  is  possibly  the  most  powerful 
of  all  three— it  asks  the  defense  acquisition  workforce  management 
to  look  at  the  people  they  have  hired  and  upon  whom  they  rely  for  the 
day-to-day  operations  of  Project  Management  Offices  (PMOs)  and  Major 
Defense  Acquisition  Programs  (MDAPs).  Not  only  are  managers  to  look 
at  their  workforce,  but  actually  articulate  how  much  they  trust  them. 
What  message  is  being  sent  if  managers  trust  their  acquisition  workforce 
to  manage  millions  of  taxpayer  dollars,  but  do  not  trust  them  to  refrain 
from  using  Twitter  at  work?  Consider  that  these  same  employees  are 
trusted  to  make  acquisition  program  decisions  that  will  affect  the  lives  of 
thousands  of  soldiers,  while  managers  may  be  reluctant  to  allow  editing 
of  documents  collaboratively.  In  one  sense,  what  this  boils  down  to  is: 
What  kind  of  culture  do  we  believe  we  have?  Henry  Jenkins,  an  author  and 
MIT  professor,  writes  about  one  such  culture  that  the  defense  acquisition 
workforce  may  do  well  to  look  toward— a  participatory  culture. 

A  participatory  culture  is  a  culture  with  relatively  low  barriers 
to  expression  and  engagement,  strong  support  for  creating  and 
sharing,  and  some  type  of  informal  mentorship  whereby  what  is 
known  by  the  most  experienced  is  passed  along  to  the  novices. 
(Jenkins  2009). 

This  is  the  kind  of  culture  that  would  seem  to  value  and  promote  trust 
among  employees  and  between  supervisors,  leadership,  management, 
and  their  employees  on  the  front  lines  executing  their  direction.  Make  no 
mistake:  Fear,  Control,  and  Trust  are  all  issues  that  must  be  dealt  with  to 
successfully  exploit  the  rich  capabilities  that  social  media  offer  us. 

Again,  the  quote  that  began  this  article  speaks  to  the  need  to  avoid 
assumptions  of  the  past  in  order  to  move  forward;  do  not  discount  this 
in  dealing  with  the  three  horsemen— their  power  to  restrain  us  lies  as 
much  within  our  organizational  designs  as  any  real  or  realized  problem 
or  vulnerability.  Bill  Gates,  speaking  in  2005  to  the  National  Governor’s 
Association,  had  a  similar  warning.  The  topic  was  education  but  the 
message  was  just  as  clear.  He  asserted  that: 
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America’s  high  schools  are  obsolete.  By  obsolete,  I  don’t  just 
mean  that  our  high  schools  are  broken,  flawed,  and  under¬ 
funded— though  a  case  could  be  made  for  every  one  of  those 
points.  By  obsolete,  I  mean  that  our  high  schools— even  when 
they’re  working  exactly  as  designed— cannot  teach  our  kids  what 
they  need  to  know  today.  Training  the  workforce  of  tomorrow  with 
the  high  schools  of  today  is  like  trying  to  teach  kids  about  today’s 
computers  on  a  50-year-old  mainframe.  It's  the  wrong  tool  for  the 
times.  (Gates,  2005) 

Those  of  us  who  work  in  training  and  education  within  DoD  need  to 
share  a  similar  concern.  The  argument  is  not  that  all  we  do  is  obsolete;  the 
argument  is  that  unless  we  adapt,  improvise,  and  overcome  our  issues  with 
regard  to  Fear,  Control,  and  Trust  within  our  own  organizations,  we  may 
well  be  sustaining  a  model  that  is  functioning  perfectly  as  designed,  but  the 
design  itself  may  be  insufficient  for  current  and  emerging  requirements. 
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FIGURE  4.  RISK  MATRIX 


Category  Risk  (RIN) 


Supportability 

(Low/Moderate) 


FSR  Support 
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PM  Support  concept  (multifunctional 
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•  Stovepipe  support  structure 

•  Incorporation  of  FSR  Experience  Into 
Design  Process 

•  Downsizing  of  FSR  Personnel 


Mitigation  (Handling) 


Simplify/Stabilize  SW 
Automate  maintenance  function 
Cross-functional  FSRs  across  BC 
Dev  existing  BC  support  base  for  CPOF 
Integrate  into  the  Army  Support  Structure 


Metric  (Monitoring) 


FSR/Unit  (DIV/BDE/BN.  etc) 

Data  Integration  for  Reporting  and  Reuse 


Risk  Status 


The  System  of  System  (SoS)  Migration  Plan 
Implementation  and  the  mandated  FSR  reduction 
requirement  for  FY08  drives  this  risk. 


Risk  Assessment 


Software  Supportability/Efficiency 

•  Ability  for  CPOF  software  to  aid  in  and 
provide  a  Stable  CPOF  Network 

•  Ability  for  CPOF  to  be  upgraded  and  fixed 
as  needed,  on  the  fly  and  from  a  remote 
location. 

•  SW  Documentation 
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•  Garbage  Collection 

«  64  Bit  Backup  Processes 


Deploying  'SuperTech'  developer  to  theater 
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Computer  Resource  Utilization/Available 

SW  Quality  Level 

Used  Standards  Metric 

Reliability  (Fault  Tolerance,  recoverability) 

Maintainability  (Stability,  changeability) 

Operational  Ability  (Ao) 


Current  development  tasks  are  designed  to  increase 
the  ability  of  the  baseline  3.0.2  Software  to  aid  in 
the  supportability  area.  Development  remains  on 
track  but  the  technical  difficulty  of  implementation 
drives  this  risk  to  be  moderate. 


Hardware  Support  &  Acquisition  Processes 

•  Hardware  Availability  and  Lead  Time  to 
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•  End  of  Life 
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Buffer  Supply  of  hardware  to  deploy  as  needed 
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UID 

CM  Process,  Documentation  and  Enforcement 


Estimated  vs.  Actual  Delivery  Times 
Maintenance  Downtime 
Repair  Cycle  Time 
Parts  Availability 


Contact  Is  in  place  for  the  acquisition  of  hardware 
and  support.  The  implementation  of  a  Configuration 
Management  process  will  be  in  place  by  FY07  thus 
helping  reduce  the  risk. 


Training 

•  Training  structures  integrated  into 
mainstream  Battle  Command  Support 
Structures 


Inclusion  of  an  embedded  trainer. 

Training  and  Support  package  for  NET,  TRADOC 
and  Sustainment 


Actual  vs.  Planned  #  of  personnel  attending 
Training  Systems  Available 
Student  Proficiency  /Skill  Level 
Training  Level  vs.  Proficiency 


Logistics  Products  are  currently  being  developed  to 
improve  current  training  and  to  meet  the  First  Unit 
Equipped  Date  (FUED). 
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Technical 

(Moderate) 


incompatible  Versions  of  Fielded  Software 
Bug  Fixes  and  Patch  Upgrades 
Inadequate  Evaluation  of  SW 


Implementation  of  Multiple  CPOF  Networks 
PASS  to  Exchange  Information 
Field  New  Units  CONUS 

Evaluate  and  Determine  Criticality  of  Bug  Fixes 
and  Patches.  If  possible  Roll  Up  to  decrease  system 
upgrade  times. 

Remote  Admin  push  of  small  critical  updates 


#  and  Version  Type  of  CPOF  Networks 
tt  of  Total  SW  Bugs  vs.  #  Critical  SW  Bugs 
Percentage  of  Total  Critical  Bugs  Fixed 


Currently,  Bugs  are  identified,  evaluated  and  rolled 
up  into  fixes  and  patches  based  on  prime  ’s 
processes.  New  implementation  calls  for  GOV 
approval  and  structuring  of  Patches,  Fixes  and 
Smaller  Releases  to  allow  for  identification  of 
critical  elements  and  establishment  of  acceptable 
timeframes. 


Current  Software  Limitations 
No  Full  spectrum  Ops 
No  Ruggedization 
Limited  Interoperability 
Theater  Requested  Enhancements 
Marine  Requested  Enhancements 


Expectation  Management 
Customer  Awareness 

Evaluate  and  Implement  Important  Theater/ 

Marine  Requests  using  out  Quick  Reaction  Theater 
Development  Support  and  Prime  SW  Development 
Team 


ft  Theater/Marine  Requests  Outstanding 
Average  Implementation  Time  of  Theater/Marine 
Requests 


Currently  CPOF  Block  2  Requirements  do  not 
provide  complete  Full  Spectrum  Capability  to 
the  Warfighter.  Currently  effective  customer 
management  by  PO  and  FSR  Personnel  help  to  give 
Customers  an  understanding  of  when  capability 
will  become  available.  Most  new  requirements  are 
processed  and  approved  by  the  TSM. 
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FIGURE  4.  RISK  MATRIX 


